Question sur CocoaPods
Karoxys
Membre
Bonjour,
J'ai vu dans certain ticket qu'il y avait des experts pods sur le forum :-)
Ma question porte sur les update, je m'explique.
Dans certain cas, comme par exemple une librairie que j'utilise dans un de mes projets "MMDrawerController" qui permet de faire les slides à droite ou a gauche (à la Facebook). Dans mon cas, l'écran qui se trouve droite a un fond noir, du coup je dois appliquer un layer blanc à la place d'une layer noir (par défaut). Du coup, je modifie la librairie comme ceci :
// CUSTOM MODIFY - BEGIN
centerView.layer.shadowColor = [[UIColor whiteColor] CGColor];
// CUSTOM MODIFY - END
Donc mon problème c'est si je dois modifier une librairie annexe en faisant un "pod update", je perds mes modifications ...
Est-ce qu'il est donc possible de mettre à jour en excluant quelque librairie ? ou au pire en sélectionnant une librairie ? par exemple un pod update 'maLib'.
Merci pour vos réponses :-)
K.
Réponses
Oui tu peux indiquer dans ton Podfile que quand tu veux la librairie 'MMDrawerController' tu ne veux pas qu'il la récupère depuis le repo officiel mais depuis autre part. Cet "autre-part" ça peut être :
1) Une copie locale
Et comme ça c'est la version se trouvant dans le chemin indiqué qui sera utilisée
2) Un fork de la librairie, si tu as décidé de faire un fork du repo GitHub officiel MMDrawerController dans ton propre GitHub pour pouvoir faire tes modifications dedans, et faire pointer ton Podfile dessus :
Tout est expliqué ici dans les Guides de CocoaPods
Personnellement je te conseille la 2e solution (fork) qui a l'avantage de te permettre de proposer ensuite une Pull Request à l'auteur de MMDrawerController, pour l'inciter à merger tes modifications (ton fork) dans son repo officiel, et ainsi intégrer ton code dans la version officielle de MMDrawerController.
NB : Le seul truc pour que ce mécanisme marche (= pour pouvoir pointer vers un emplacement spécifie où se trouve MMDrawerController autre que l'emplacement connu officiellement par CocoaPods), il faut juste que tu aies un fichier "MMDrawerController.podspec" (ou MMDrawerController.podspec.json) à la racine du répertoire vers lequel tu pointes. Mais c'est déjà le cas de MMDrawerController (comme de la plupart des pods d'ailleurs}. Au pire si ça n'avait pas été le cas il aurait suffit de copier celui de CocoaPods/Specs (ou d'utiliser la commande "pod spec cat") pour le générer.
Hello !
Merci pour tes conseils AliGator.
Je vais mettre en place la solution 2 car c'est la plus propre effectivement.
Par contre, en tant qu'utilisateur je trouve ça un peu contraignant.
Est-ce qu'il y a des les tuyaux côté CocoaPods un upgrade de l'action update ?
Personnellement, mais je ne sais pas si vous avez eu des retours là dessus, j'aurais aimé par exemple des commandes tels que "pod update --all" ou "pod update --lib maLib". Car si on choisit la solution 1 (qui implique de modifier le podfile à chaque fois) ou la solution 2 (plus élégante effectivement, mais qui oblige de se créer un fork de la lib. Mais j'avoue que cette option est quand même intéressante si la lib est utilisé dans plusieurs projet) par défaut l'outil nous fait un update de toutes les librairies ce qui n'est pas tip top d'après moi.
Après je ne connais pas vos contraintes et je n'ai pas toutes les clefs. Mais de mon point de vue, je pense que les utilisateurs serait contant d'avoir une solution 3 afin de paramétrer la mise à jour de nos librairies (toutes, quelque une ou une seule).
Tu en penses quoi ?
K.
Après, c'est loin d'être simple, car CocoaPods est un outil de gestion de dépendances. Et du coup par définition, tu peux imaginer les complications si tu demandes de mettre à jour juste ta lib MaLib mais que cette mise à jour tire potentiellement des dépendances qui doivent elles aussi être mises à jour... et que ces mises à jour de dépendances ne sont plus compatibles avec le reste... Bref tout le moteur de gestion de dépendances qu'il y a derrière n'est pas simple.
Je pense que ça existe, jamais testé par contre. ( il me semble que la pull request est mergé).
https://github.com/CocoaPods/CocoaPods/pull/1999
@AliGator
Ouais je comprend mieux du coup ^^ Je me doutais bien aussi que si c'était pas fait c'est qu'il y avait une raison.
Mais je retiens le coup du fork ce n'est pas trop mal ! La seule contrainte que je vois c'est qu'il faut avoir un repo git pour ses libs. Mais sinon rien de bien méchant.
Merci pour tes réponses en tout cas !!
Bon bah j'ai rien dit, on supporte déjà en fait ! (c'est tout récent, ça date d'un mois ^^)
De ce côté on est donc un peu ISO avec ce qui se fait dans le monde Ruby, avec "bundle update" vs. "bundle install" " pour ceux qui connaissent Ruby et son outil Bundler
---
Il n'empêche que si ton but n'est pas de "ne mettre à jour qu'un certain pod" mais plutôt de "modifier un pod existant pour corriger un bug ou rajouter un truc qui te manque", la solution est vraiment un fork ou une copie locale, car tu es en train de corriger une lib et donc il faut mieux en créer une version à part contenant tes corrections.
Tant pour pouvoir faire une Pull Request à l'auteur plus tard que pour faire un suivi de version efficace et éviter qu'un "pod update" complet ne t'écrase tes modifications.
- Si tu n'as pas de compte GitHub mais utilise GIT quand même (ce qui devrait à mon avis être une obligation, je ne conçois même pas qu'on puisse travailler sur un projet sans avoir un repo GIT, même si on ne l'utilise que localement sans aucun serveur ni GitHub ou autre), tu pourras commiter ta version locale modifiée de MMDrawerController avec le reste de ton projet, comme ça il sera versionné et tu pourra voir l'évolution de tes modifications dessus au même titre que celles de ton projet, et si ton projet dépend de certaines modifications que tu as faites dans MMDrawerController (ton projet utilise une @property de MMDrawerController que tu as rajouté toi-même, etc) le tout suivra en parallèle.
- Si tu n'as ni GitHub ni GIT, déjà il est urgent que tu y remédies en passant au minimum à GIT même sans compte GitHub... et puis sinon bah ça change pas que tu peux pointer sur un dossier local à ta machine aussi.
Ah oui bien sur que je bosse avec un repo GIT. Mais j'utilise bitbucket de mon côté et pas github. C'est pour ça que je dis que ce n'est pas trop méchant comme contrainte et que je préfère également la solution numéro 2 (fork).
Voire pousser le truc plus loin et permettre de personnaliser un les divers paramètres de la shadow, pas que sa couleur mais aussi le reste (radius, ...)
Oui je vois, avoir plus une réflexion de faire évoluer la librairie, qu'une réflexion concernant les besoins de nos projets uniquement. C'est ce que je vais faire. D'ailleurs comme tu le dis, le fait de faire fork implique une vision plus constructive des librairies qu'on utilise.
Je vais pousser la logique dans ce sens ;-)
Thx !