Cocoapods, sans rire ?
Smy
Membre
Hello
Je vais me faire lyncher, c'est sur, mais voici un coup de gueule sur cocoapods. J'ai testé hier pour la première fois ce bidule, et je ne comprends pas l'engouement général (et depuis plusieurs années).
L'installation est risible, comment sérieusement demander à un développeur une installation en " sudo " ? Merci pour les règles de sécurité de base.
Ensuite, la gestion des dépendances et l'installation dans le projet. Je trouve que cocoapods s'intègre très mal à Xcode et la création du Workspace est pour moi rédhibitoire. Je n'ai peut être pas compris la logique, mais je ne retrouve plus mes petits après une " cocoapodisation ".
Enfin, c'est peut être le principe même du système qui me rebute, mais je trouve risqué de vouloir à tout prix être sur la version la plus récente de tous les frameworks. Les développeurs de frameworks sont faillibles, et les risques de regresssions ne sont pas neutres...
Voilà . Je retourne à ma gestion manuelle des frameworks ???
Réponses
(je viens de réaliser que j'avais posté dans " Xcode et Developer Tools ", pas certain que ce soit le bon endroit)
Tu peux tout à fait préciser une version particulière du pod dans ton podfile, et même par exemple, de dire ">=1.0.3 et < 2.x". Voir la doc.
Pour ce qui est du Workspace, je trouve que c'est un bon compromis. Le seul inconvénient étant qu'il faut ouvrir le workspace et plus le projet.
Non vraiment, le seul vrai inconvénient est quand tu veux utiliser tes propres bibliothèques précompilées, il faut absolument créer tes pods privés, sinon c'est galère. Et c'est chiant de créer un pod privé pour ça.
Ah je n'avais pas vu ça, j'aurais aussi beaucoup aimé :-)
Le problème c'est que c'est du Ruby, et que pour installer des gems avec le ruby du système, il faut être root. Ils n'y peuvent rien, c'est comme ça...
L'autre solution (celle que j'utilise), c'est d'utiliser rvm, qui a plusieurs avantages:
(Edit: Bon sinon, moi ce qui me fait raler, ce sont les puces qui apparaissent dans l'éditeur du forum, mais pas sur le message final...
).
Bon faut dire que de toute façon ça c'est à cause de Ruby effectivement et la config par défaut de OSX pour Ruby qui force à installer les gems niveau système. Que ce soit CocoaPods ou n'importe quelle autre gem c'est pareil pour slather, fastlane ou n'importe quelle autre.
Moi ça fait un bail que j'ai changé la config par défaut d'OSX pour que ma GEM_HOME soit dans mon répertoire utilisateur et pas dans mon système, comme ca plus besoin de sudo.
C'est juste que c'est ton OSX qui est configuré de façon "risible" comme tu dis. Pour le coup c'est pas CocoaPods qui est mal configuré, c'est ton RubyGems installé par défaut dans OSX qui est configuré pour installer les gems dans le système, mais si tu reconfigures bien ton OSX y'a pas de problème. C'est pareil pour Homebrew, pour Synx, pour Slather, pour n'importe quelle gem.
Mais loooool on ne doit pas avoir la même vision d'une organisation "propre".
Donc toi tu préfères fouttre en vrac toutes tes librairies dans ton projet, plutôt que de les avoir proprement séparées et éviter de polluer ton projet donc ?
L'avantage de CocoaPods c'est qu'en créant un workspace, il n'est pas intrusif. Il ne touche pas à ton code de ton appli à toi, il garde les libs séparées.
Et surtout, je viens de récupérer un projet qui date et qui a été fait sans CocoaPods, je peux te dire que j'ai galère. Il utilisait des libs dépréciées (iOS5 ou iOS6) sauf que pour savoir quelle était la version qui avait été copiée/collée dans le projet de l'app, et si les anciens développeurs avaient modifié le code de la librairie pour y mettre leurs propres patchs crados (pour faire les mises à jour " obligatoires pour avoir les librairies qui peuvent encore compiler avec Xcode 7 et être acceptées sur l'AppStore " c'est super galère...)
Alors qu'avec CocoaPods, je choisis la version que je veux et je fais un pod update et il me met à la version que je veux j'ai pas à faire la maintenance.
Après, que tu ne sois pas habitué à utiliser un workspace plutôt qu'un projet, je peux l'entendre. Mais quand tu vois les avantages par rapport à tout mettre en vrac dans ton projet (surtout pour les mises à jour plus tard), tu t'y fais vite et après tu te demandes pourquoi tu n'y es pas passé plus tôt.
Heiin ?? Mais qui t'oblige à faire ça ?! Bien sûr que non tu n'es pas obligé de pointer sur la dernière version de tous les frameworks !
Et sinon si tu n'aimes vraiment pas les workspaces, tu peux toujours utiliser "cocoapods --no-integrate" ou même CocoaPods-Rome qui va te compiler les librairies en .framework et te laisser ensuite les ajouter à ton projet à l'ancienne comme tu fais habituellement.
Mais au moins pour tout le reste (la gestion de version, de dépendances, la résolution de conflits, les mises à jour sur demande, ...) c'est automatisé, plutôt que de ne plus savoir sur quelle version tu es et de galérer à mettre à jour à la main si jamais en plus un collègue à toi a modifié le code d'origine comme un porc.
Ou alors tu peux aussi utiliser Carthage, qui est pareil que CocoaPods pour la résolution de dépendances et les mises à jour, sauf qu'il te laisse ensuite tout faire à la main. Mais à part ça c'est le même principe pour l'utilisateur, une liste de librairies, la résolution des dépendances et la récupération des bonnes versions demandées mais compatibles entre elles, la gestion de conflits de versions sémantiques, les mises à jour... c'est surtout ça le plus important qu'apporte un gestionnaire de dépendances, qu'il s'agisse de CocoaPods, Carthage, ou SwiftPackageManager (qui justement pour l'instant je fais pas la RD donc a une utilité limitée en attendant qu'ils le fassent évoluer)
Oui, j'attendais la réponse d'Ali
Je fini un truc et je réponds aussi.
Ca y est, j'ai réussi à t'énerver AliGator. Bon, vu ton implication dans Cocoapods, c'est normal, mais ce n'était pas le but recherché.
Ok, sauf que c'est :
- Ce qui est indiqué sur la page d'installation de Cocoapods
- L'installation de base de Mac OS
Tu déplaces le problème sur Ruby ou RubyGems, mais dans ce cas pourquoi avoir développé Cocoapods en Ruby ?
Ok, je te l'accorde.
- d'où vient le code (quel repo GIT, est-ce le code de l'auteur d'origine, un fork, ou c'est peut-être même pas sur GitHub mais BitBucket ou même un truc que tu as dû télécharger sur le site de l'éditeur en ZIP...)
- quelle version du composant tu as copié/collé dans ton projet
- de plus rien n'empêche ensuite un développeur peu consciencieux de modifier le code d'une lib directement dans son projet ce qui fait que le jour où il décide de la mettre à jour comme il aura oublié qu'il a fait le patch il va tout écraser sans réaliser que c'était une version custom.
Et ceci pose un gros problème quand 3 mois après tu dois mettre à jour (à la main en plus) t'es librairies parce que par exemple tu veux passer au BitCode et que seule les dernières versions de telle lib supportent le BitCode etc
(Cela pose problème aussi pour l'attribution aussi mais c'est un autre débat, la plupart des devs s'en foutent malheureusement des licences et de citer les libs qu'ils utilisent et leurs auteurs)
Sauf si tu gardes un changelog propre (et je ne parle pas des commentaires du commit).
Après, oui, pour le développeur bordélique, un gestionnaire de frameworks et de dépendances peut aider
Cocoapods ne règle rien à ça, on est d'accord.
Non ce qui ne me plait pas dans ton message, c'est le ton.
Plutôt que de demander "n'y a-t-il pas un moyen d'installer CocoaPods dans ma home plutôt que via sudo, car je n'aime pas utiliser sudo", tu es tout de suite parti dans la critique. Alors que tu aurais posé la question, je t'aurai volontiers donné au moins 2 solutions pour se passer de sudo (déplacer ta $GEM_HOME de RubyGems, ou utiliser l'application CocoaPods.app qui sandbox tout et ne dépend pas du Ruby système)
Le ton agressif et l'attaque gratuite directement n'est pas le bon moyen pour avoir des réponses positives sur n'importe quelle communauté. Relis n'importe quel Code of Conduct de n'importe quelle communauté (y compris par exemple celle de Swift Open Source ou même de CocoaPods) et puis même sans ça c'est du bon sens.
Dire d'un outil (de surcroit OpenSource et développé sur le temps libre) que "c'est nul" non seulement ce n'est pas constructif, mais en plus cela ne va pas inciter les gens à t'aider. C'est un peu comme si je disais "t'es qu'un gros connard fils de pute" au lieu de "je t'invite à reformuler ta question de façon plus polie, par exemple tu pourrais demander comment on peut se passer de sudo ça serait plus constructif". Ou comme remonter un bug sur un logiciel en disant "c'est nul ça marche pas" plutôt que soit d'aider à corriger le problème (surtout si c'est un outil OpenSource) soit au moins expliquer le soucis que tu as eu et donner des détails.
Sauf que c'est pas le principal intérêt de CocoaPods. Le but premier de CocoaPods c'est pas juste de te télécharger tes frameworks et les installer dans ton workspace, c'est surtout de résoudre les dépendances de ton graphe de dépendances. Et ça si t'as à le faire à la main, c'est une vraie prise de tête et des Duplicate Symbols à gogo. Ceci dit ça n'arrive que quand tu commences à utiliser plusieurs frameworks qui ont des dépendances communes, ce n'est peut être pas encore ton cas si tu n'as que des petits projets. (mais ça arrive vite quand tu as des projets plus gros)
Non on n'est pas d'accord. CocoaPods génère automatiquement un Manifest, contenant la liste de toutes les librairies que tu utilises et leur contrat de licences. Il génère ça à la fois en Markdown (pour la version "lisible directement") et sous forme d'un PLIST correspondant à panneau à mettre dans ton Settings.bundle.
Cela permet ainsi pour ceux qui le souhaitent de simplement copier ce plist dans leur Settings.bundle et d'avoir une entrée "Contributions" qui affiche toutes les libs, les remerciements et les licences à cet endroit.
Tout ceci est encore une fois automatisée donc tu n'as plus qu'à copier le fichier si ça t'intéresse (après tout le monde ne le fait pas non plus, on ne veut rien imposer, mais au moins si tu veux le faire c'est très simple comparativement à si tu avais à le faire à la main).
Ah oui, je t'ai vraiment énervé alors. On se croise depuis 5 ou 6 ans ici, et tu sais que je ne suis pas un agressif.
Je ne cherchais pas à avoir des réponses, je constatais qu'un outil n'était pas pour moi.
Oui, j'aurais pu poser des questions sur le sudo, j'aurais même pu tout faire tout seul si j'avais eu envie de le faire. Sauf que si vous annoncez sur la home de cocoapods qui faut faire un sudo, 99% des utilisateurs vont le faire. Même des développeurs.
Ensuite, mon message était argumenté, je n'ai pas dit que c'était nul comme tu l'entends, j'ai expliqué pourquoi je n'aimais pas, point par point. A la limite, je peux concevoir que le terme "risible" ait pu te choquer, tu m'en excuseras.
Et la grande majorité de mes développements iPhone sont sur mon temps libre, et je ne prends pas mal quand j'ai des critiques.
Heu sur la home de CocoaPods, déjà on indique "Using the default Ruby install will require you to use sudo when installing gems." ce qui pour moi cela implique donc que si t'as re-configuré ton Ruby pour plus qu'il installe tout dans le système. Mais surtout, juste en dessous, on a un gros titre en rouge "Sudo-less installation" qui décrit tout pour si tu veux pas utiliser sudo. C'est écrit juste en dessous du paragraphe "Installation", avec un titre en rouge "Sudo-less Installation", je sais pas trop comment on peut faire plus clair :
https://guides.cocoapods.org/using/getting-started.html
Et enfin, si tu penses que les instructions ne sont effectivement pas assez claires et qu'on pourrait améliorer cela pour mieux expliquer aux personnes qui débarquent sur CocoaPods, pourquoi ne pas essayer plutôt d'être constructif et nous faire un retour en nous suggérant une présentation différente de ce guide ou nous suggérant de formuler cela autrement ?
Nous ne sommes pas omniscient et nous ne sommes que des hommes derrière tout ce code, on ne connait pas forcément le niveau de chacun et les problèmes que tout le monde peut rencontrer, surtout quand nous on est baignés dedans depuis longtemps, donc nous accueillons avec plaisir les propositions d'amélioration de la documentation.
Ou peut-être que tu n'avais pas consulté le guide d'installation sur https://guides.cocoapods.org/mais autre part, et dans ce cas là peut-être pourrais-tu nous indiquer où tu as lu cette documentation qui n'est sans doute pas assez à jour par rapport aux guides complets, et nous proposer de corriger cela pour améliorer nos documentations.
Tu peux ouvrir une issue sur GitHub, ou même mieux faire une Pull Request pour proposer une autre formulation dans la documentation qui te semblerait plus claire (d'ailleurs je crois que le paragraphe "sudo-less installation" a été rajouté par qqn d'extérieur via une Pull Request justement pour aider les autres qui voudraient faire ça aussi), ou même me demander gentillement ici sur les forums de modifier la formulation en en proposant une autre qui te semble plus compréhensible si l'existante ne t'a pas parue claire pour quelqu'un qui débute sur CocoaPods. Ca sera toujours plus constructif, plus agréable, permettra d'aider les autres, et c'est le but du développement Open Source et communautaire après tout.
Leçon du jour : ne pas se lancer dans la découverte d'un nouvel outil quand on est grognon.
Et surtout ne pas poster dans cet état car c'est un état qui se transmet assez facilement.
Dans ce cas, je te suggère plutôt de manger un lapin cru (ou un chat...).
Non, pas sur l'accueil, tu as une partie INSTALL qui ne parle pas de Sudo-less. Pourquoi dans ce cas aller lire la partie Getting Started si l'accueil est censé être suffisant ?
Alors oui, si vous avez une version sans sudo, je ne comprends même pas que vous parliez de sudo.
C'était plutôt de l'humour, j'écrivais ça avec le sourire. C'était juste que j'avais en tête deux sujets qui étaient critiques, l'un sur Apple et l'autre sur Cocoapods.
Ou un écureuil, comme les vampires végétariens dans les séries tv, où les monstres créatures étranges ressemblent à des ados de 16 ans et fréquentent les lycées pour draguer fréquenter des jeunes filles de 15 ans.
Maintenant on boucle, Olivier est bien énervé, alors que ce n'est pas une attaque personnelle. Je vais attendre que cela se calme.
Et non, pas d'histoire de "Code of Conduct", on peut critiquer un projet si c'est argumenté. Je ne posais pas de questions, je ne voulais pas en poser.
Je suis peut être le seul, mais je réfléchis toujours avant de faire un sudo.
Vous trouviez que Cocoa Café devenait trop calme (http://forum.cocoacafe.fr/topic/14315-y-a-t-il-un-flic-pour-sauver-cocoacafe/), voilà une bonne petite polémique pour tout relancer.
Il est sur qu'on peut facilement se passer de cocoapods, on le faisait avant on pourra le faire après... Par contre je suis en ce moment sur un projet un peu gros avec pas mal de dépendance et c'est vrais que c'est super pratique.
J'ai cependant pas du tout étudié comment créer des pod privé et je regrette un peu. Je quitte le projet bientôt et j'aurais pas le temps de le faire mais ça serait bien quand même.
De plus avec le plugin que je viens de découvrir par hasard il est vraiment simple de gérer ces dépendances sans sortir d'xcode et sans ouvrir le terminal. ça change pas la vie mais c'est un peu plus convivial.
J'ai pour l'instant aucun grief contre Cocoapods les seuls soucis que j'ai avec c'est moi qui me les suis créés en tant que boulet national.
Pour de petit projet fait seul on s'en passe facilement dès que l'on développe a plusieurs c'est quand même bien de pouvoir unifier la gestion des dépendances sans avoir à tout formaliser, on a un outil on l'utilise et ça marche.
Quand je découvrirais un bug (ça peut arriver) alors je râlerais en bon français mais au moins je sais que je trouverais un bonne âme pour m'aider c'est aussi l'avantage d'utiliser des outils communautaires.
Pour le sujet du ruby je me suis pas documenté mais quelqu'un connait un avantage de l'installation par défaut si le fait de bouger la home enlève des inconvénients est ce qu'il en rajoute pas d'autre?
Je ne suis pas un pro du terminal non plus c'est quoi les dangers réel du sudo?
Je demande ça ici parce que c'est un peu le nerf de la guerre et que le moment n'est jamais mal choisi pour apprendre
Pour le calme de cocoacafé c'est pas la peine non plus de le mettre à feu et à sang pour essayer de remettre de l'ambiance
Tu donnes les droits super utilisateur à ce que tu vas exécuter. Donc il faut que tu fasses totalement confiance car tu ouvres totalement ton mac.
::)
On peut critiquer si c'est argumenté, mais c'est quand même plus agréable (et plus constructif) d'aider à améliorer les choses plutôt que de dire "c'est risible" et critiquer, non ?
C'est comme si je te disais "ton détecteur de loups garous il est nul il plante c'est ridicule c'est honteux de faire une appli comme ça" plutôt que "bon je vois pas l'intérêt de ton appli mais bon je l'ai testée quand même et tu pourrais la rendre plus sympa à mon avis en faisant tel truc". Ca s'appelle l'esprit communautaire et être positif.
Il y a une différence entre être critique et proposer des solutions d'améliorations (j'ai jamais dit que CocoaPods était parfait, il est loin de l'être, et ce n'est qu'avec les contributions des gens que l'on peut s'améliorer) et être critique juste pour critiquer, même si c'est argumenté (c'est le "merci pour les règles de sécurité de base" que tu appelles ton argumentation ? je vois pas trop)
Non tu n'es pas le seul, la preuve puisqu'il y a un paragraphe dédié pour expliquer comment faire une installation sudo-less dans le guide et que c'est un paragraphe qui nous a été demandé d'ajouter (via une Pull Request) dans la documentation (parce que la personne nous a fait un retour pour nous améliorer, on ne peut pas penser à tout surtout sur un projet aussi massif que CocoaPods c'est pour ça que les contributions sont importantes)
Là ou nous ne nous comprenons pas, c'est que tu me reproches de critiquer plutôt que d'essayer de faire avancer le sujet. Sauf que pour faire avancer le sujet, encore faut-il que je dépasse le stade initial de la surprise et que je m'intéresse au sujet. J'ai abandonné avant.
J'ai installé hier Cocoapods pour la première fois parce qu'un des frameworks que je voulais tester le recommandait. J'ai eu comme première surprise, violente à mon sens, de voir le sudo (c'est ici, sous INSTALL : https://cocoapods.org).Il est possible d'utiliser Cocoapods en ne lisant pas autre chose que la page d'accueil et ses "onglets" INSTALL et GET STARTED, ce que j'ai fait.
Ma seconde surprise a été la façon d'intégrer les frameworks téléchargés, je ne m'attendais pas au workspace et je n'ai pas aimé.
Du coup, j'ai posté ça ce matin. Je me doutais que des membres de ce forum me contrediraient, d'où mon introduction, mais pas que tu réagirais aussi violemment. J'avais totalement oublié que tu étais partie prenante à Cocoapods, donc je ne t'attaquais pas personnellement, j'y ai repensé en fin de matiné. J'attaquais Cocoapods en lui même et ses choix d'implémentation.
Après plusieurs messages de ta part, je découvre que mes deux reproches sont contournables. Franchement, quand tu vois les critiques sur Cocoapods ailleurs, je ne suis pas le seul à ne pas aimer les workspaces et pas le seuil à ne pas savoir que le système peut être différent.
J'ajoute les liens, et il y en a des pages si tu cherches.
http://blog.mugunthkumar.com/articles/the-problem-with-cocoapods/
http://chaosinmotion.com/blog/?p=935
http://blog.mosheberman.com/why-i-dont-use-cocoapods/
Je te cache pas que la première réaction que j'ai eu quand j'ai essayé Cocoapods pour la première fois était un peu similaire: ça me semblait la grosse artillerie. Et puis à l'époque, ça ne marchait pas.
Sa perception a évolué dans mon esprit. Déjà , parce que depuis deux ans, ça marche vraiment bien. Ensuite parce quand on étudie la question, on comprend que c'e n'est pas forcément faisable sans sortir la grosse artillerie. D'ailleurs ça explique pourquoi ça ne marchait pas trop au début: il a fallu beaucoup d'effort pour tout faire fonctionner à cause de la complexité. Par exemple " je ne sais pas si c'est toujours vrai " il faut puller TOUTES les podspecs depuis github quand on installe Cocoapods. ça prend des plombes. On peut sans doute améliorer ce point, mais ça demande beaucoup d'efforts.
Dans un sens, Carthage est plus intéressant, justement parce que l'architecture est plus simple. Mais dans les faits, comme elle utilise des frameworks, ça te limite à iOS 8 minimum, et il y a même eu des problèmes pour passer la validation, parce qu'Apple voulait que toutes les frameworks soient signées. Si je devais choisir aujourd'hui, je préfèrerais quand même Cocoapods.
Ca tu as tout à fait le droit de ne pas aimer les workspaces. Perso (CocoaPods ou pas d'ailleurs) dès qu'il y a besoin de découper proprement un projet, je préfère, mais je peux comprendre que chacun ses goûts. Maintenant, c'est le choix qu'a fait CocoaPods car cela simplifie énormément les choses, en séparant de façon claire le projet contenant les librairies de ton projet de ton app, comme ça on limite énormément les risques de pourrir ton projet à toi en travaillant sur un truc séparé. Ca évite de gérer aussi tous les cas (car chacun configure son projet d'application un peu comme il veut, et ce serait difficile de contenter tout le monde ou d'imposer à tout le monde d'organiser son propre projet d'application exactement d'une certaine manière y compris les réglages projets, flags, Build settings & co.
Du coup en faisant un projet à part dédié pour les Pods et mettant ça dans un workspace, on évite de tout casser et de frustrer les utilisateurs s'ils utilisent une organisation de leur projet qu'on aurait pas prévue. Donc le but est d'être le moins intrusif possible, et le plus simple à utiliser pour un nouveau venu sans lui demander de changer la configuration de son projet ou de faire des actions manuelles pour terminer l'intégration des libs.
Mais après il fallait bien faire un choix. On aurait pu à la place ne pas faire de workspace et aller modifier ton projet d'application pour intégrer les frameworks nous-même dans ton projet, au risque de tout casser si tu ne l'as pas organisé comme on imagine. Ou bien on aurait pu rendre l'option "--no-integrate" comme étant le comportement par défaut et te laisser faire l'intégration dans ton projet toi-même.
Mais 95% des gens ne savent pas comment _correctement_ intégrer des librairies tierces à la main (j'entend pas là quand il y a une librairie externe par exemple qui nécessite certains Build Settings, Search Paths, ressources additionnelles, etc... à configurer et qu'un simple drag & drop du framework ne suffit pas) et du coup disaient "ça marche pas" (plutôt que d'être constructif eux aussi...) alors que c'est juste qu'ils ne savaient pas comment configurer correctement Xcode, qu'on a fait le choix de, par défaut, faire l'intégration en workspace pour leur faciliter la tâche. Mais CocoaPods est fortement configurable si tu veux faire autrement que le comportement par défaut, donc si tu ne veux pas des workspaces tu peux toujours faire --no-integrate
En quoi ceci est différent ?
CocoaPods ce n'est pas une entité toute seule indépendante. Comme tout logiciel, derrière il y a des gens. Et d'autant plus comme derrière tout logiciel Open Source, derrière il y a des gens qui donnent de leur temps libre pour fournir un logiciel " qui plait ou ne plait pas, chacun ses goûts " mais donnent du temps gratuitement pour améliorer le quotidien de la communauté. Même si je ne faisais pas partie de CocoaPods, ton comportement m'aurait je pense aussi choqué (bon OK peut-être moins directement, mais quand même).
Il faut comprendre que l'OpenSource est une communauté, donnant de son temps gratuitement. Critiquer un outil Open-Source, c'est critiquer sa communauté (et pourtant j'ai fait plusieurs communautés OpenSource, et celle de CocoaPods est celle que j'ai trouvé la plus ouverte et la plus agréable, justement en préférant accueillir et aider ceux qui veulent contribuer même s'ils ont un faible niveau, plutôt que de les envoyer balader et dire que leur niveau de dev est risible, et c'est ce qui m'a fait me mettre à Ruby car ils m'ont donné envie de m'investir plutôt que de me jeter la pierre).
Je pense que tant qu'on n'a pas participé à de l'OpenSource c'est sans doute difficile à concevoir, pourtant je pensais que la participation active à un Forum tel que CocoaCafé t'aurai donné goût aux mêmes problématiques. A savoir si quelqu'un dit " ce forum c'est de la merde (critique), on n'a pas de réponse au bout d'une heure ("argumentaire") " bah c'est normal que muqaddar et même que tous les membres actifs de CocoaCafé se sentiraient attaqués par ce genre de remarque. Le "ah mais je n'attaquais pas muqaddar ou toi Ali ou Céroce, je critiquais juste le forum" n'y changerait rien, la critique d'une communauté c'est la critique de ses membres.
Ne pas oublier qu'il y a des humains derrière tout le temps passé à développer ces outils. Tu as le droit de ne pas les aimer, tu as le droit de ne pas les utiliser s'ils ne te plaisent pas, mais s'il y a un truc qui ne te plait pas c'est quand même plus civil, courtois et respectueux de signaler "tiens j'ai trouvé cet aspect là rédhibitoire du coup je vous en informe" plutôt que de crier sur un forum "c'est risible cet outil, ils se foutent de notre gueule avec leur sudo". C'est une question d'état d'esprit et de comportement communautaire. A une époque on appelait ça la Netiquette.
Sauf que gueuler et dire que c'est risible ne va pas faire évoluer les choses.
Alors que nous le signaler avec une Issue sur le GitHub pour qu'on soit au courant et corrige la documentation pour mieux signaler les possibilités alternatives (laisser l'utilisateur faire l'intégration s'il n'aime pas les workspaces, mieux signaler la documentation indiquant comment installer sans sudo dès la page d'accueil, ...) ça te prend 2mn et au moins ça fait avancer les choses. Mais bon j'ai l'impression que c'est pas trop ton trip l'esprit communautaire et l'entre-aide en fait, c'est dommage pour un membre d'un forum comme CocoaCafé.
J'étais prudent au début avec Cocoapods parce que comme mentionné il fallait ouvrir un workspace spécifique et que je me demandais comme pour toute utilisation de librairies tierces qu'est ce qui se passerait si un changement majeur arrivais sur iOS ?
Mais finalement on se met au jeu facilement et rapidement. Moi j'aime bien sa facilité même si j'arrive jamais à me souvenir des commandes et des peu de lignes qu'il faut mettre dans le Podfile alors qu'elles sont simples. Et puis je n'ai pas parcouru suffisamment la documentation pour configurer au mieux le fichier.