›

Mise à  jour majeure de CocoaPods

AliGatorAliGator Membre, Modérateur
mai 2014 modifié dans Xcode et Developer Tools #1
Bonjour à  tous,

L'équipe CocoaPods (dont je fais maintenant partie) vient de sortir une mise à  jour majeure (0.33.0) qui modifie pas mal de choses.

Entre autres, maintenant les podspecs publiés sur https://github.com/CocoaPods/Specs vont maintenant être associés chacun avec un (ou plusieurs) propriétaire(s) du podspec, et seul le(s) propriétaire(s) d'un podspec auront le droit de le modifier ou proposer de nouvelles versions.

La soumission d'un nouveau podspec (d'un nouveau Pod, ou d'une nouvelle version d'un Pod existant) ne se fera plus à  l'aide d'une "Pull Request" sur le repo CocoaPods/Specs, mais via le terminal et la ligne de commande "pod trunk push".
Ainsi, tout un chacun pourra soumettre ses propres Pods sans être obligé de faire une Pull Request (et de polluer un peu les "issues" du repo GitHub et d'attendre qu'on ait le temps de valider ces Pull Requests).

--- POD EXISTANTS

Du coup si vous avez déjà  publié vos propres Pods sur CocoaPods, je vous invite à  réclamer leur propriété via ce formulaire. Plus de détails sur cet article dédié du Blog.
NB: Pendant cette période de transition, la soumission de nouveaux Pods est bloquée, le temps qu'on arrive à  un état stable où tous les Pods ou presque ont été réclamés.

--- NOUVEAUX PODS

Ensuite dès qu'on aura redébloqué la soumission de nouveaux Pods, vous pourrez soumettre vous-même de nouveaux Pod ou de nouvelles versions de vos Pods existants via la commande "pod trunk push" (+ de détails dans cet article de blog).

---

NB : Tous ces changements ont également pour conséquence que les specs du repo CocoaPods/Specs vont être converties au format JSON lors de leur publication sur le repo. Cela ne devrait en rien impacter votre workflow habituel, mais étant donné que c'est un grand changement technique/interne de notre côté, il se peut que cela ait des effets de bord et introduise des bugs. Nous ne vous cachons pas qu'on s'attend à  devoir publier une 0.33.1 voire une 0.33.2 dans les 24/48h vu le chantier qu'a été cette 0.33...)
Mots clés:

Réponses

  • LarmeLarme Membre
    mai 2014 modifié #2

    S'rait temps que j'm'y mette tiens à  CocoaPod. Bon, ça attendra la rentrée.


    Bon courage en tout cas.


  • PyrohPyroh Membre
    #3


    S'rait temps que j'm'y mette tiens à  CocoaPod. Bon, ça attendra la rentrée.


    Bon courage en tout cas.




    Je me suis fait exactement la même réflexion en voyant le titre du topic.


    ça a l'air plutôt pas mal même si j'ai pas pris le temps d'essayer d'en comprendre tous les tenant et aboutissants.


     


    Bon courage pour la migration !

  • LarmeLarme Membre
    #4


    Je me suis fait exactement la même réflexion en voyant le titre du topic.


    ça a l'air plutôt pas mal même si j'ai pas pris le temps d'essayer d'en comprendre tous les tenant et aboutissants.


     




    En bref, simplification d'imports de bibliothèques externes, gestion comme si elles étaient internes avec des imports en "<xxx/xxx.h> et surtout leurs mises à  jours...

    Si j'ai bien tout suivi...

    Là , il s'agit surtout de rendre à  César ce qui appartient à  César, via de " l'authentification " d'auteurs, mais surtout pour sûrement éviter des abus d'updates foireux qui a dû avoir lieu par des personnes externes...

  • AliGatorAliGator Membre, Modérateur
    #5
    CocoaPods, ça va beaucoup plus loin que ça :
    - Intégration facilité de bibliothèque tierces en effet comme mentionné par Larm
    - Facilitation de leur Mà J également en effet
    - Mais aussi (et limite *surtout*) gestion de dépendances.


    1) Ainsi si tu trouves la lib A sympa, et qu'il se trouve que la lib A a besoin du framework système F (disons CoreData.framework) pour fonctionner, mais dépend aussi de 2 autres libs tierces B et C, alors CocoaPods va automatiquement t'installer dans ton projet la lib A, mais aussi la lib B et la lib C, et configurer ton projet pour qu'il importe automatiquement le framework F.

    Fini les galères d'avoir à  ajouter les frameworks qu'il faut

    2) Plus fort encore, si la lib A dépend de la lib B en version 1.2 ou supérieur, et que la lib C dépend de la lib B en version 1.3 ou supérieur, CocoaPods va résoudre les dépendances et d'une part ne récupérer qu'une seule vois la lib B (ne pas intégrer 2x la lib B dans ton projet) mais en plus va voir qu'il faut qu'il prenne la version 1.3 de cette lib minimum pour être compatible à  la fois avec A et C.


    Bref, sans CocoaPods, tu vois le cauchemar que ça peut devenir que de résoudre toutes les dépendances entre tes libs, surtout si chaque lib dépend de versions différentes d'autres libs. Alors qu'avec CocoaPods il s'occupe de tout.

    Et c'est surtout cet aspect "gestion de dépendances" + "gestion des versions sémantiques" qui est intéressant, ça t'évite de tout casser et d'y perdre dans les versions et dans quelle version de quelle lib tu utilises & co.
  • Paisible.frPaisible.fr Membre
    #6

    Ouais, conclusion : il faut que je m'y mette egalement :-)


     


    Bravo pour le travail accompli par l'equipe de CocoaPods.


  • colas_colas_ Membre
    mai 2014 modifié #7

    @Aligator


     


    Une remarque : Pour les pod perso, on reste à  une gestion type git j'imagine : à  chaque nouvelle version, ajouter un dossier et le podspec dedans.


     


    Une remarque-question : lors de la mà j, j'ai l'erreur (je l'ai déjà  eue pour la 0.33) :



    
Fetching: cocoapods-core-0.33.1.gem (100%)
    
ERROR:  While executing gem ... (Gem::FilePermissionError)
    
You don't have write permissions for the /Library/Ruby/Gems/2.0.0 directory.

    Apparemment, c'est dû à  mavericks !! cf. http://stackoverflow.com/a/19958086/1670830


    Ce lien contient aussi une solution à  ce problème.


     


    Je ne sais pas si sudo -s puis gem install cocoapods est équivalent à  sudo gem install cocoapods


  • AliGatorAliGator Membre, Modérateur
    mai 2014 modifié #8

    Une remarque : Pour les pod perso, on reste à  une gestion type git j'imagine : à  chaque nouvelle version, ajouter un dossier et le podspec dedans.

    Oui pour les repos privés rien ne change. Soit tu fais tout à  la main, tu ajoutes un dossier avec comme nom le numéro de la version, et tu mets le podspec dedans, et tu push tout ça sur ton repo GIT de Specs, etc... soit tu utilises la command faite pour, à  savoir "pod repo push" (anciennement nommée "pod push")

    Will private repositories need to adopt the JSON format?
    No. Moreover, the pod push command will keep the old behaviour, except that we are moving this into pod repo push to emphasise the distinction. Just keep in mind that if two files are available CocoaPods will prefer the JSON format.

    Donc si tu ne connaissais pas "pod push" et faisait tout à  la main, c'est le moment de découvrir "pod repo push" ;)
  • AliGatorAliGator Membre, Modérateur
    #9

    Une remarque-question : lors de la mà j, j'ai l'erreur (je l'ai déjà  eue pour la 0.33) :

    Fetching: cocoapods-core-0.33.1.gem (100%)
    
ERROR:  While executing gem ... (Gem::FilePermissionError)
    
You don't have write permissions for the /Library/Ruby/Gems/2.0.0 directory.

    Heu ça ça n'a pas grand chose à  voir avec CocoaPods à  proprement parler, mais avec Ruby et RubyGems. Les gems Ruby (comme CocoaPods ou plein d'autres) sont par défaut installées via la commande "gem install" dans le répertoire "/Library/Ruby/Gems/2.0.0". Répertoire qui appartient au système.
    Donc le plus simple est d'utiliser "sudo" ("sudo gem install ...").

    Tu pourrais aussi changer $GEM_HOME pour demander d'installer les Gems dans un autre répertoire que /Library/Ruby/Gems, mais plutôt un dans lequel tu as les droits (qui risque alors d'être un de tes répertoires persos, ce qui veut dire que la GEM ne serait installée que pour ton utilisateur et pas les autres...) mais il faudrait alors t'assurer que ce $GEM_HOME soit bien conservé entre 2 lancements de terminal... bref c'est plutôt une solution à  conseiller pour ceux qui comprennent un peu comment marche le shell et le terminal " ce qui n'a pas forcément l'air d'être ton cas donc évitons de t'embrouiller)

    Tout ça (répertoires système, utilisation de sudo pour avoir les droits admin temporairement, ...) sont des considérations qui sont génériques, venant d'UNIX, et ne sont pas directement liées avec CocoaPods, tu aurais le même problème avec une autre RubyGem, ou avec une autre commande qui cherche à  installer des choses dans tes répertoires système.

    ---

    Ce n'est pas du tout spécifique à  Maverics d'ailleurs (ce que dit la réponse StackOverflow, c'est juste que depuis Maverics, Ruby a été mis à  jour de 1.8.4 à  2.0.0, ce qui fait que les GEMS sont maintenant recherchées dans /Library/Ruby/Gems/2.0.0 et non plus dans /Library/Ruby/Gems/1.8.4. Donc si tu avais installé CocoaPods avant Maverics, à  l'époque où tu utilisais Ruby 1.8.4, alors il aura été installé dans /Library/Ruby/Gems/1.8.4 et du coup si tu mets ensuite OSX à  jour vers Maverics, Ruby 2.0.0 ne trouvera plus ces GEMS et il faudra que tu les réinstalles (ou que tu les déplaces du dossier 1.8.4 vers le dossier 2.0.0).

    Mais avant Maverics et du temps de Ruby 1.8.4 il y avait exactement le même principe de permissions, /Library/Ruby/Gems étant un répertoire système, dans les 2 cas il a toujours fallu utiliser "sudo" pour pouvoir installer des choses dans les répertoires système.
  • colas_colas_ Membre
    #10
    Pfffff a vrai dire j'ai mis du temps à  m'y mettre, j'ai galéré pour y arriver, j'ai passé mille ans à  découper mon projet en Pod et j'ai ai toujours pas bénéficié de tous ces efforts, même si ça m'a obligé à  découper des classes, etc.


    Un beau projet, difficile et à  vrai dire un support pas optimal.


    En tout cas merci, j.espere et je pense que je profiterai bientôt de tous ces efforts.
  • AliGatorAliGator Membre, Modérateur
    #11
    Si tu as galéré pour y arriver, c'est sans doute qu'il y a certains concepts de base que tu n'as peut-être pas bien compris/assimilé ?

    Si tu as passé un temps fou à  découper ton projet en pods, par contre ça ça sous-entend que le découpage de ton projet à  la base avant même CocoaPods était mal fait et que ton projet était déjà  un plat de spaghettis. Ce genre de symptôme est typique d'une architecture mal découpée et mal isolée (ne jamais oublier le principe d'encapsulation de la POO et de séparer les responsabilités de chaque classe, si toutes tes classes dépendent les unes des autres c'est sûr que tu auras du mal à  faire des modules proprement indépendants ;))

    ---

    Si tu as des questions n'hésite pas, on a mis à  jour les guides il y a quelques temps (voir le travail de Michele) donc ça devrait être plus clair, mais même si pour un cas d'usage classique on peut s'y mettre en très peu de temps (installer CocoaPods, créer son Podfile, un pod install et boum c'est fini), il y a certainement encore pas mal à  faire côté docs pour les newbies.

    C'est vrai que pour commencer (pour qqun qui n'a jamais installé ni manipulé CocoaPods) le plus simple est quand même de comencer en tant qu'utilisateur/consommateur de pods (tu te crées un projet vite et tu fais juste un Podfile qui va lister des pods existants qui t'intéressent " comme AFNetworking, OHHTTPStubs, MagicalRecord, ... " et un "pod install" plus tard tu as un workspace tout prêt. Ca pour démarrer dans l'apprentissage de CocoaPods pour ceux qui n'ont jamais fait c'est nickel.

    Et la création de tes propres Pods (plutôt que juste utiliser ceux existants sur le net comme AFNetworking & co) ça viendra sans doute plutôt dans un 2e temps, quand tu seras prêt à  ne plus être juste un consommateur de pods mais aussi un producteur de pods, soit juste pour toi pour les garder pour tes projets persos, soit en les publiant carrément à  la communauté pour que tout le monde en profiter. C'est pas bcp plus compliqué que d'être juste consommateur, mais c'est vrai que pour un nouveau venu sur CocoaPods, chaque chose en son temps ;)
  • colas_colas_ Membre
    mai 2014 modifié #12
    Oui, mais pourtant un des vrais plus de cocoapod est la gestion de ses propres pods !


    Ps : à  la base je voulais créer mes propres pods en local, sans avoir besoin de faire un push vers un serveur. Je peux bien sur dans podfile faire référence à  un projet en local, mais pour pouvoir profiter du versioning, j'ai l'impression qu'il faut gitter. ça a donc été l'occasion de créer des nouveaux repository, etc.


    Je n'ai pas vu la nouvelle doc, mais l'ancienne était très rapide sur les sous-pods, la question des pch. Quand on a des questions, on nous dit d'aller sur SO, mais il n'y a pas forcément de réponses. A mon avis, il faudrait plus de samples de code (pas juste des lignes, mais des exemples complets), d'autant plus que le repo Spec ne va plus être dispo.
  • AliGatorAliGator Membre, Modérateur
    #13
    Le repo spec continuera d'être dispo les podspec seront toujours hostés sur GitHub c'est juste que pour publier un podspec tu ne vas plus avoir à  faire une Pull Request et devoir attendre qu'on la valide, tu vas utiliser la ligne de commande. Mais le podspec finira toujours sur le GitHub CocoaPods/Specs à  la fin.

    Cf le joli schéma avec le chien dans le post du blog ^^
  • AliGatorAliGator Membre, Modérateur
    #14
    Mais sinon c'est noté pour la doc on va regarder ce qu'on peut faire sur ces points. Le mieux reste d'ouvrir une issue sur le GitHub de guides.cocoapods.org pour nous dire ce qu'il te manque comme info qu'on sache quoi compléter.
  • muqaddarmuqaddar Administrateur
    #15

    C'est un clone de RubyGems pour Cocoa quoi !


    (podfile = gemfile, pod install = bundle install)


  • LarmeLarme Membre
    mai 2014 modifié #16

    @Ali:


    Du coup, j'ai commencé à  regarder un peu le site et notamment la recherche avec mon oe“il de nouveau v'nu.

    Je me demande si celle-ci pourrait être améliorée...

    Genre, les repo qui ont le plus de stars ? Après, c'est peut-être pour avoir un truc plus équitable, mais ceux qui commencent par les premières lettres de l'alphabets arrivent en premier...

    Ou peut-être trier sur ceux qui sont au minimum passé en 1.x ?


    Après, je sais, c'est peut-être pas l'intérêt de CocoaPods de faire de la recherche GitHub améliorée, voire si leur recherche le permet, mais peut-être d'indiquer le nombre d'Issues/Issues Resolved/Pull Request, ou la date de la dernière Mà J. ça permettrait de donner les signes de vie d'un pod. Pas trop envie de reprendre un truc qui est délaissé et bourré de bugs... Ou afficher une liste des derniers pods ajoutés/mis à  jour.


  • AliGatorAliGator Membre, Modérateur
    #17

    C'est un clone de RubyGems pour Cocoa quoi !
    (podfile = gemfile, pod install = bundle install)

    C'est exactement l'idée, d'ailleurs on s'inspire pas mal de RubyGems pour le DSL et les concepts.
  • AliGatorAliGator Membre, Modérateur
    #18

    @Ali:
    Du coup, j'ai commencé à  regarder un peu le site et notamment la recherche avec mon oe“il de nouveau v'nu.
    Je me demande si celle-ci pourrait être améliorée...
    Genre, les repo qui ont le plus de stars ? Après, c'est peut-être pour avoir un truc plus équitable, mais ceux qui commencent par les premières lettres de l'alphabets arrivent en premier...[/quote]
    Oui, ça c'est prévu. En fait le but n'est pas d'aller regarder le repo github.com/CocoaPods/Specs mais de regarder le site qui référence les pods (à  moins que tu ne parles d'une autre page, de quelle page listant les pods tu parles en fait au juste ?)
    En tout cas, on est en cours de refonte également (oui, y'a du boulot, on ne chôme pas !) pour la partie search du site, et on a prévu d'afficher ce genre d'infos. Je note.

    Mais bon, GitHub liste les dossiers par ordre alphabétique, c'est comme ça, donc si tu veux une liste de pods (et leur version et leur nombre d'étoiles etc) propre et formattée, il faut aller sur le site officiel (je te retrouve l'adresse tout à  l'heure si j'y pense) et pas utiliser le listing du repo GitHub ;)
    [/quote]

  • LarmeLarme Membre
    #19

    Je parle du moteur de recherche sur CocoaPods.org.

  • AliGatorAliGator Membre, Modérateur
    #20
    Ok en effet.

    Je t'invite alors à  remonter une "issue" sur le GitHub de cocoapods.org pour remonter cette demande (en ayant pris soin de vérifier auparavant qu'il n'en existe pas déjà  une à  ce sujet)

    https://github.com/CocoaPods/cocoapods.org/issues
  • AliGatorAliGator Membre, Modérateur
    mai 2015 modifié #21
    Pour ceux qui disaient dans ce thread qu'ils vaudraient vraiment qu'ils se mettent à  CocoaPods, c'est le moment où jamais : Google a annoncé lors de la GoogleIO que CocoaPods serait leur voie de distribution maintenant officielle pour distribuer leurs diverses libs et SDKs iOS (GoogleAnalytics-iOS-SDK, Google-AdMob-iOS-SDK, ...)

    A cette occasion, ils ont même produit une petite vidéo expliquant aux débutants de CocoaPods comment s'y mettre :D

    Du coup, plus d'excuse !

    (Plus d'infos sur ce sujet dédié sur le forum)
Connectez-vous ou Inscrivez-vous pour répondre.