Cocoapods

rhizomes · mars 2013

La gestion des dépendances, l'inclusion et le maintien de sources, librairies et "Frameworks" tiers, posent des problèmes délicats.

Pour les résoudre j'utilise le plus possible depuis quelques mois cocoapods.

Et vous, utilisez-vous cocoapods?

Pourriez-vous partager vos retours d'expérience ?

Céroce · mars 2013

oui. (Faut développer ?)

rhizomes · mars 2013

@Céroce mon message a été publié avant que je n'ai fini de l'écrire... J'en suis confus.

Smy · mars 2013

Heuu, quel est le but de cocoapods ? Leur site n'est pas d'une grande clarté.

Céroce · mars 2013

@Smy: ils partent un peu du principe que tu connais déjà 1) le problème et 2) la solution adoptée sur d'autres plateformes, en particulier Ruby (rubygems).

L'idée est qu'une appli iOS ou Mac OS a des dépendances, c'est à dire qu'elle utilise des bibliothèques tierces. Par exemple, si on crée une application client-serveur HTTP, on va sans doute utiliser AFNetworking. Une solution est d'aller sur le GitHub d'AFNetworking, le télécharger, le copier dans un répertoire près du projet Xcode, insérer les sources dans le projet et compiler.

Cette approche a deux problèmes:

les mises à jour d'AFNetworking sont compliquées; il faudra retirer tous les anciennes sources et remettre les nouvelles. Du coup, on préfère ne pas y toucher (!).
c'est fastidieux.

Par ailleurs, AliGator te le dira, il vaut mieux créer un Workspace pour séparer les bibliothèques tierces du projet.

Voilà , pour le problème. Maintenant, pour la solution Cocoapods:

1) On crée un fichier texte dans le répertoire du projet Xcode, qui s'appelle Podfile et qui décrit les dépendances:

platform :ios, &#39;6.0&#39;<br />
pod &#39;AFNetworking&#39;, &#39;~&gt; 1.1.0&#39;<br />

2) On tape

pod install

Et c'est tout!

Cocoapods va télécharger toutes les biblios, les ranger dans des répertoires, créer un workspace sous Xcode et le règler.

Par la suite, imaginons que tu veuilles passer à AFNetworking 1.2.0. Tu modifies le Podfile, puis tu tapes pod update, et c'est fait!

Il y a encore des avantages, par exemple, si ton projet est en ARC mais pas la bibliothèque, Cocoapods ajoutera tout seul les drapeaux -fno-objc-arc aux fichiers.

Le seul inconvénient est qu'il faut que quelqu'un ait préparé la biblio pour qu'elle soit listée sous Cocoapods et pour définir ses dépendances à elle.

Pour répondre à la question, je n'ai eu qu'un seul soucis lors d'un pod update. J'ai dû tout virer et refaire un pod install. Après, ça marchait nickel. Mon seul point d'inquiétude est sur son évolution quand arrivera Xcode 5 qui changera encore totalement les formats de fichiers et les concepts

/cool.gif' class='bbc_emoticon' alt='8--)' />

AliGator · mars 2013

On en a déjà parlé sur le forum, non ?

J'en avais également parlé lors de ma présentation #12 aux CocoaHeads Rennes sur les workspaces et l'intégration de librairies tierces...

Mes librairies GitHub ont été misés sur CocoaPods par des utilisateurs à l'origine, car beaucoup voulait les utiliser avec CocoaPods (du coup je suis allé voir et depuis c'est moi qui les maintiens) et maintenant je suis contributeur du projet (voire issues 141 et 841) donc oui je suis ça de près, pour mes libs comme pour le projet.

Maintenant en pratique je n'utilise pas, pour les raisons que j'ai expliquées dans la présentation CocoaHeads, parce qu'avec les workspaces et des projets séparés pour chaque lib on maà®trise mieux l'intégration et c'est aussi simple qu'un glisser-déposer

/wink.png' class='bbc_emoticon' alt=';)' />

rhizomes · mars 2013

'Smy' a écrit:

Heuu, quel est le but de cocoapods ? Leur site n'est pas d'une grande clarté.

Après avoir installé et configuré Cocoapods...

Vous créez un fichier Podfile de description des dépendances de votre projet exemple :

<br />
##<br />
# check https://github.com/CocoaPods/Specs<br />
# and http://cocoapods.org<br />
#<br />
platform :ios,&#39;5.0&#39;<br />
# AFNetworking Networking framework<br />
# git://github.com/AFNetworking/AFNetworking.git<br />
pod &#39;AFNetworking&#39;, &#39;~&gt; 1.1.0&#39;<br />
pod &#39;AFKissXMLRequestOperation&#39;<br />
# UDID<br />
# git://github.com/ylechelle/OpenUDID.git<br />
pod &#39;OpenUDID&#39;, &#39;1.0.0&#39;<br />
# Facebook Integration<br />
#http://developers.facebook.com/docs/getting-started/facebook-sdk-for-ios/3.1/<br />
pod &#39;Facebook-iOS-SDK&#39;<br />
# https://developers.google.com/mobile-ads-sdk/docs/<br />
pod &#39;GoogleAnalytics-iOS-SDK&#39;<br />

Vous tapez en ligne de commande : pod install'

<br />
localhost:SeCoucherMoinsBete bpds&#036; pod install<br />
Resolving dependencies of `./Podfile&#39;<br />
Resolving dependencies for target `default&#39; (iOS 5.0)<br />
Downloading dependencies<br />
Using AdMob (6.3.0)<br />
Using AFKissXMLRequestOperation (0.0.1)<br />
Using AFNetworking (1.1.0)<br />
Using Facebook-iOS-SDK (3.2.1)<br />
Using GoogleAnalytics-iOS-SDK (2.0beta4)<br />
Using HockeySDK (3.0.0)<br />
Using OpenUDID (1.0.0)<br />
Using PocketAPI (1.0.2)<br />
Using TTTAttributedLabel (1.6.2)<br />
Generating support files<br />

Les librairies, sont installées xcode totalement configuré.

C'est le principe d'un gestionnaire de dépendances.

Ceetix · mars 2013

Le seul reproche que j'ai à faire à ce système c'est que pour chaque application que tu créés tu as une redondances des librairies externes et communes à tes applications (genre AFNetworking est souvent utilisé partout). En te séparant de Pods tu peux n'avoir qu'un clone de AFNetworking que tu ajoutes en workspace dans tes différents projets.

Mais sinon c'est super

/smile.png' class='bbc_emoticon' alt=':)' />

rhizomes · mars 2013

'AliGator' a écrit:

On en a déjà parlé sur le forum, non ?

Je n'en avais pas trouvé trace ... d'où ce sujet.

'AliGator' a écrit:

Maintenant en pratique je n'utilise pas, pour les raisons que j'ai expliquées dans la présentation CocoaHeads, parce qu'avec les workspaces et des projets séparés pour chaque lib on maà®trise mieux l'intégration et c'est aussi simple qu'un glisser-déposer /wink.png' class='bbc_emoticon' alt=';)' />

J'utilise les Workspaces & Librairies statiques & cie depuis longtemps, et cela n'est pas incompatible avec la notion de gestionnaire de dépendance au contraire même. Le problème de l'approche "workspace à la mano" c'est le suivi des mises à jours et des dépendances et configurations complexes.

Smy · mars 2013

Merci pour vos explications. Je me doutais bien que c'était un truc dans le genre.

Par contre je suis surpris de ce fonctionnement, car cela implique que toute nouvelle version d'un framework est forcément meilleure que l'ancienne. Vous faites donc du coup une confiance aveugle dans les tests réalisés par les développeurs/contributeurs des frameworks. Et les régressions ?

Je n'ai pas cette logique, je teste longuement un framework avant de décider de l'utiliser, et je le considère stable une fois inclus. Je ne décide donc de faire une mise à jour qu'en cas de besoins...

rhizomes · mars 2013

'Smy' a écrit:

Par contre je suis surpris de ce fonctionnement, car cela implique que toute nouvelle version d'un framework est forcément meilleure que l'ancienne. Vous faites donc du coup une confiance aveugle dans les tests réalisés par les développeurs/contributeurs des frameworks. Et les régressions ?

Je n'ai pas cette logique, je teste longuement un framework avant de décider de l'utiliser, et je le considère stable une fois inclus. Je ne décide donc de faire une mise à jour qu'en cas de besoins...

Il est tout à fait possible de fixer les versions.

<br />
<br />
# git://github.com/AFNetworking/AFNetworking.git<br />
pod &#39;AFNetworking&#39;, &#39;1.1.0&#39; <br />
<br />
<br />

Fixera la version de AFNetworking.

<br />
# git://github.com/AFNetworking/AFNetworking.git<br />
pod &#39;AFNetworking&#39;, &#39;~&gt; 1.1.0&#39;<br />

Déterminera qu'il convient d'utiliser une version supérieure ou égale à 1.1.0

rhizomes · mars 2013

Pour les cas plus complexes j'utilise une approche à la "Aligator" mais en "automatisant" les processus de mise à jour. Supposons que cela concerne AFNetworking .

Je crée un Fork pour projet sur GitHub.com
Je clone le projet.
Je "créé une dépendance" GIT : git remote add official https://github.com/A...FNetworking.git
J ajoute dans un script de synchronisation gitSync.sh :

<br />
# AFNetworking<br />
<br />
cd AFNetworking/<br />
git fetch upstream<br />
git checkout master<br />
git rebase upstream/master<br />
cd ..

Il suffira d'éxécuter : . gitSync.sh pour synchroniser le projet.

Cette approche fonctionne bien, il faut néanmoins importer les éventuels nouveaux fichiers dans le projet.

Elle permet par contre d'intégrer des "pull request" qui auraient été rejetées par le projet officiel.

Il est possible de faire pointer un "Podspec" vers le "clone local synchronisé".. la boucle est bouclée.

samir · mars 2013

'rhizomes' a écrit:

Elle permet par contre d'intégrer des "pull request" qui auraient été rejetées par le projet officiel.

Moi je trouve ça trés génat, et meme dangereaux si le script intègre des pull request refusées.

lifely · mars 2013

'rhizomes' a écrit:

Pour les cas plus complexes j'utilise une approche à la "Aligator" mais en "automatisant" les processus de mise à jour. Supposons que cela concerne AFNetworking .

...

Cette approche fonctionne bien, il faut néanmoins importer les éventuels nouveaux fichiers dans le projet.

Elle permet par contre d'intégrer des "pull request" qui auraient été rejetées par le projet officiel.

Il est possible de faire pointer un "Podspec" vers le "clone local synchronisé".. la boucle est bouclée.

Une autre solution que je te / vous propose également. La plupart des système de gestion de dépendance sont en général plutôt bien penser pour comme dit précédemment utilise une version X ou Y. Tellement bien penser que tu peut également spécifier un repo github, un commit.

Une lecture de la doc a cet endroit, montre qu'il est possible de spécifier un repo et donc un fork personnel d'un projet X ou Y.

http://docs.cocoapods.org/podfile.html#pod

Have Fun with it !

Cocoapods

Réponses