Griefs contre Cocoapods
Tof
Membre
@Pyroh ;Moi aussi je préfères Carthage. J'ai été un utilisateur de CocoaPods avant. Mais je trouve Carthage moins intrusif que CocoaPods vis à vis de Xcode. On est pas non plus dépendant d'un repository centralisé. Et surtout ce qui me plait c'est que j'ai pas à gérer l'env pour Ruby ou devoir perdre du temps à faire du Ruby. Je préfères passer ce temps à faire du Swift !
Perso j'utilises plusieurs frameworks dans mon projet avec Carthage et j'ai pas d'effet poupée russe. Du coup ça passe très bien sur l'AppStore. Avec Carthage tu peux avoir des dépendances entre Framewoks sans qu'ils soient pour autant imbriqués les uns dans les autres. Comme par exemple AlamofireObjectMapper qui défini des dépendances sur Alamofire et ObjectMapper. Tu devrais sans doute faire quelque chose de similaire pour tes propres frameworks.
Réponses
- Notez l'existence depuis plusieurs mois maintenant de l'application indépendante CocoaPods.app, qui permet de s'affranchir de votre environnement Ruby, donc même si vous avez flingué pour une raison X ou Y votre environnement Ruby par défaut de OSX et que votre Ruby ne marche plus ou quoi, on s'en fout, CocoaPods.app est du "tout embarqué" et indépendant de votre config locale.
- On peut tout à fait demander à CocoaPods de ne pas faire l'intégration (flag "--no-integrate" lors du "pod install") et faire l'intégration nous-même. On peut aussi utiliser CocoaPods-Rome (c'est ce que je fais sur un de mes projets) pour que ça génère juste des .frameworks et que tu les glisses toi-même dans ton projet (donc comme Carthage en fait)
@AliGator je suis passé il y a pas longtemps sur Cocoapods 1.0 car malheureusement j'ai encore des projets qui utilisent des composants qui ne sont pas encore passés sur Carthage. Je me traines donc CocoaPods. Je serai bien resté avec la 0.39.0 mais par le passé les gas qui gèrent CocoaPods avaient rendu obsolètes la version que j'utilisais ( j'avais pas encore eu le temps de basculer sur la nouvelle version et je ne suis pas le nez collé à leur site) et ce sans prévenir. Ils m'ont foutu dans une belle merde. Du jour au lendemain plus aucun projets ne buildaient. On ne pouvait plus faire de release pour les clients. Bien évidemment la nouvelle version était pas compatible avec l'ancienne. J'ai du migrer dans l'urgence 32 pods plus tous les projets qui les utilisaient. Je les ai maudits ! Depuis je fais mon possible pour réduire ma dépendance à CocoaPods. Plus récemment j'ai du migrer un projet qui fonctionnait bien avec la version 0.39.0 et ça c'est mal passé. Après investigation j'ai du allé dans le fichier project.pbxproj virer ce qu'avait mis la version 0.39.0 car la version 1.0 n'a pas fait d'elle même le ménage. Des paramètres de mon projet ont aussi sauté au passage. ça m'a fait perdre 2j pour avoir de nouveau un projet fonctionnel. Ce genre de mésaventure avec CocoaPods n'est pas nouveau. Par le passé en changeant de version de CocoaPods j'ai déjà eu des pbs similaires. Contrairement à CocoaPods Carthage ne bidouille pas dans les fichiers d'Xcode. Et rajouter son framework dans le projet avec Carthage est trivial.
Enfin bref tous ça pour dire que je préfères, et de très loin, Carthage à CocoaPods et que ça n'est pas prêt de changer ! Tous mes anciens pods sont sur Carthage et au fur et à mesure des versions je vires des projets tous les composants qui ne sont pas compatibles avec Carthage.
C'est marrant j'ai eu l'expérience inverse (en tant qu'auteur de lib surtout) avec Carthage. Ou c'est plein d'inconvénients, entre autres le fait que ça nous oblige a créer un projet et toutes les targets pour toutes les plateformes (il commence à y en avoir un sacré paquet avec Apple maintenant, watchOS, tvOS, et j'en passe) ce qui est déjà contraignant, ils d'obligent aussi à changer toute la structure de ton repo GIT si tu veux rendre ta lib disponible avec Carthage (il faut qu'elle ait la structure attendue sinon il perd ses petits), et ils ont changé les formats qui ont cassé mes builds plusieurs fois. Et ça c'est sans parler des problèmes que ça pose de par le fait que ça build des binaires embarquant le runtime swift (car tout le monde te demande des binaires précompilés) et du coup lors du passage de Xcode 7.2 à 7.3 y'a plus aucune release de libs qui ne marchait vu comment leur système est fait. Alors que pour CP j'ai rien eu à modifier.
Bref y'a des inconvénients à chaque méthode, et de plus maintenant que CP est justement passé en 1.0 les choses ne devraient plus changer (les fois où elles ont changé auparavant on a toujours justifié, par exemple pour la nouvelle orga du repo de specs " qui sera transparente pour tous les utilisateurs de CP 1.0 " cela nous a été imposé par GitHub à cause du succès de CocoaPods qui leur générait un trop fort traffic (cf article de blog + discussions avec les équipes GitHub qui se sont faites de façon ouvertes sur l'issue GH dédiée) et donc qu'il a fallu adapter l'infrastructure au succès du projet.
Que ça t'ait posé des soucis je n'en doute pas le moins du monde, mais je pense que c'est surtout une mauvaise expérience d'une fois qui t'a du coup dégoûté du produit, c'est dommage... d'autant que je suis coupable dans la même chose de mon côté, mais pour Carthage, où il m'a donné tellement de boulot supplémentaire en tant qu'auteur de librairie que je préfère de très loin éviter de l'utiliser, car c'est beaucoup + de maintenance pour les auteurs de libs que SPM ou CP.
Mais bon, l'important c'est que chacun trouve la solution qui lui convienne après tout, on ne peut pas plaire à tout le monde
Le jour où ils ont bloqué la version de CocoaPods qu'on utilisait et que du jour au lendemain on pouvait plus builder aucun de nos projets. Qu'on avait du faire patienter comme on avait pu nos clients qui attendaient leur application. Il y avait de quoi à être mécontent. Surtout quand les mainteneurs nous disaient que c'était comme ça un point c'est tout. Et que si on était pas content on n'avait qu'à se trouver un autre outil ça passe encore moins. Du fait de la gestion centralisé des composants ils peuvent bloquer facilement l'accès quand ça leur chante. On c'était senti pris en otage en plus d'être dans la merde. C'était inacceptable. Cette histoire nous avait causé un lourd préjudice à l'époque. Alors on avait suivi leur conseil. On avait cherché un autre outil. Et c'est grâce à eux qu'on avait fini par trouver Carthage. Avec Carthage on avait enfin un outil développé en Swift (exit Ruby et son environnement !) et plus de gestion centralisé des composants. On devrait leur dire merci !
Effectivement. Mais plaire n'est pas le mot que j'emploierai. C'est plus une question de pérennité et de risques. CocaPods était l'un des premiers outils dans son genre pour iOS. On a eu le tord de le truster dans un cadre professionnel. On s'en est mordu les doigts !
Mais bon de toute façon je penses qu'à terme on finira tous par passer sur SwiftPM. J'ai d'ailleurs assez hate qu'il soit releasé officiellement. Avoir un solution officielle écrite en Swift pour la gestion des composants c'est une excellente chose pour Swift et son développement future.
Quand on basculera dessus on parlera en rigolant de nos mésaventures passées avec CocoaPods et Carthage ;-)
Ne le prends pas mal, mais cette situation est votre faute. C'est un problème potentiel qu'on a avec tous les gestionnaires de dépendances. Je m'explique.
Déjà , voici un article qui cause d'un problème similaire avec node.js et son gestionnaire de dépendance, npm:
http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
En gros, le dév a retiré de la circulation un module ultra populaire. Comme tout le monde l'utilisait, plus personne ne pouvait déployer une appli node.js.
Avec Cocoapods ou Carthage, on a le même problème. Si un module vient à disparaà®tre de github, on ne peut plus builder. Ce qu'il faut faire est donc de mettre le répertoire /pods sous gestion de version, comme le reste de l'appli. Ainsi on dispose toujours du code source, même s'il n'est plus distribué.
Je tiens à dire que je n'en voyais pas l'intérêt (pourquoi perdre de la place et du temps à stocker tous les pods, alors qu'on peut les récupérer à tout moment ?), jusqu'à ce que je comprenne dans quelle merde on pouvait se fourrer.
Après, je ne sais rien de l'attitude des gens de Cocoapods qui t'on répondu, mais c'est un travail bénévole, et de leur point de vue, vous êtes encore des relous qui n'ont pas lu l'annonce qu'ils ont faite il y a deux mois et qui prévenait du changement. Je comprends aussi votre point de vue: on est pris dans notre travail quotidien et nos multiples projets, et on a un peu autre chose à faire qu'aller voir les annonces sur cocoapods.org. Alors on ne s'y intéresse que quand ça ne marche plus.
"On a eu le tord de le truster dans un cadre professionnel."
Ou comment reconnaà®tre ses "tords", sans vraiment les reconnaà®tre, tout en accusant les autres.
Et en méprisant en bonus ceux qui avait l'impression de faire un travail professionnel avec cocoapods.
Est-il possible qu'il existe une manière "professionnelle" d'utiliser cocoapods mais que vous ne soyez pas parvenu à la trouver ?
Je ne le prend pas mal car je ne me sent pas fautif vue le contexte. Le fait qu'il fasse évoluer CocoaPods n'est pas le problème. ça fait partie de l'évolution normale d'un produit. C'est plus la manière de comment ils gèrent ça qui pose problème. Comme tu le dis on est tous pris par nos projets. On est pas le nez rivé à leur site. Par contre l'outil on le lance souvent. Ils auraient pu penser à afficher un message pour nous dire que la version allait devenir obsolète quand on lance un 'pod install'. Quand tous a planté ils auraient pu aussi réactiver la version afin de nous laisser le temps pour que l'on bascule sur la dernière version. ça aurai était une attitude faire plais au lieu de nous envoyer blackbouler. Si en plus en plus dans les nouvelles versions ils faisaient plus attention à l'existant on basculerai plus facilement sur les nouvelles versions. Là à chaque nouvelle version c'est plus ou moins le bordel. On est obligé de bidouiller les projets à la main et de retoucher tous les pods. Du coup pour passer sur une nouvelle version on est obligé de le planifier bien à l'avance pour migrer les projets et les composant. ça a un coup en temps et donc en argent qu'on peut difficilement faire payer aux clients. Le fait que ça soient des bénévoles et que le projet soit open source devrait encore plus les motiver à faire les choses bien car c'est un moyen de montrer leur savoir faire. ça ne devrait pas être une excuse pour justifier certaines lacunes.
Enfin bref c'est pas le tout mais moi j'ai du boulot...
Je ne sais pas trop.
J'ai tendance d'une part à cloner sur mon Mac quitte à lui bousiller son espace les repos vraiment vitaux pour mon projet (essentiellement du AFNetworking, du MagicalRecord, etc., quitte à rediriger le fetch du pod vers mon clone local) pour m'éviter une m*rd* potentielle un jour, pour la même raison que le p'tit code en .js cité précédemment.
Moi j'aime bien CocoaPods en soit, cela me permet une intégration plus rapide, mon seul vrai gros soucis, c'est sûrement le Ruby et la manière dont c'est géré, ou plutôt la manière dont Apple a fait du ménage de sécurité (plus de vrai " root " par défaut), etc. C'est bien pour Mme Michu, mais pour moi, en tant que développeur, faut que je " rebidouille " derrière alors que j'avais un environnement stable et fonctionnel.
Bon, j'ai cru comprendre que CocoaPods.app permettait de m'affranchir peut-être de ça, il faudra que je creuse. Parce que sinon, je ne lui ai pas trouvé de grand intérêt (oui, y'a un UI, mais bon). Par contre, si seulement on pouvait resizer cette fenêtre de départ car certains nom de mes podfiles n'apparaissent pas entièrement. Et si on pouvait éditer les PodSpecs avec, notamment une aide à leur création ?
Concernant la pérennité, c'est de la faute de tout le monde je dirais.
C'est pour ça qu'Ubuntu et Cie ont dû mal à percer en entreprise, où seules quelques versions comme Fedora (RedHat), etc le peuvent, car tu as un support client. Sous Microsoft et Apple, c'est toujours le cas.
En bref, si tu utilises du libre, quand tu as un soucis, tu ne peux pas vraiment gueuler contre quelqu'un.
Mais cela revient au même pour les librairies que ce soit sous Carthage ou CocoaPods qu'on utilise.
J'ai lu vos posts ! Je n'utilise ni CocoaPods ni Carthage ! (je sais c'est un tort)
J'ai quand même 2 remarques/questions (hors du fondement de la discussion)
Carthage n'est-elle pas déjà détruite ?
et "tord" ne doit-il pas s'écrire "tort" ?
Tablier, est-ce que tu utilises git au moins ?
Bah, apparemment, CocoaPods s'est allié à Rome contre Carthage. Pas de Chartiers !
Parfois ! Mais plus souvent, je récupère des choses sur les git(s) des projets connus ! Hatari et autres.....
Chartiers ?
1.Je ne vois pas trop la complexité d'installer un environnement Ruby stable (15 minutes ?).
2.J'utilise Ruby et RubyGems depuis 10 ans maintenant. Je n'ai jamais eu de gros soucis à part des MAJ de gems à faire pour des problèmes de compatibilité. Je pensais que c'était pareil avec CocoaPods ou Carthage.
3.Je n'utilise pas CocoaPods ni Carthage, car j'aime bien ajouter mes dépendances "à main levée" pour avancer à mon rythme actuellement. Le tout sous Git. Oui, je suis un peu plus frileux avec mon projet Cocoa.
4.J'ai essayé CocoaPods au tout début, et ça m'avait cassé des trucs dans mon projet Xcode, mais je n'ai pas réessayé depuis, donc je ne me prononce pas.
5. Je crois qu'il y aura un gestionnaire de packages sous Swift bientôt non ? Est-ce que ça ne va pas tuer les 2 autres ?
Les mecs, n'oubliez quand même pas que CocoaPod, c'est des gens passionnés qui ont mis au point ce truc pour aider les autres à inclure facilement des bibliothèques.
Alors que vous aimiez pas, que vous préfériez autre chose ou que vous ne compreniez pas, c'est une chose mais quand même, il me semble important de préciser que c'est un outil dans l'esprit partage et open source et que dans ce contexte, je trouve incorrect de faire du "bashing". Le nb d'heure passer par ces mecs sur le projet, ca se respecte.
Personnellement, je ne suis pas un spécialiste de l'intégration de frameworks & Co mais j'ai su utiliser CocoaPods et l'utilise encore à ce jour. Alors sans doute qu'il n'est pas parfait mais quand même, globalement, il fait le job.
C'est vrai qu'avec les nouveaux XCode et les modules packages (je sais plus le nom exact), l'avantage d'utiliser CocoaPod est moins évident. Mais fut un temps ou la question se posait moins.