Aujourd’hui, pas grand chose — parce que j’ai pas trop eu le temps de m’en occuper pour être tout à fait honnête — mais j’ai tout de même pris le temps d’ajouter la bibliothèque d’Access42 sous forme de sous-module Git dans notre dépôt.
Ça permettra de conserver une version à jour de leur outil et éventuellement de leur faire des propositions — on appelle ça des pull requests
en anglais — pour améliorer l’intégration dans des applications tierces.
Je pense entre autre aux libellés de traduction ; on verra plus tard si ça s’avère nécessaire.
Vous pouvez observer que ce sous-module a été inclus dans un sous-répertoire lib du répertoire principal du plugin. Le choix du nom est arbitraire[1] et idéalement, par exemple pour des logiciels qui utilisent plusieurs bibliothèques, il eut été préférable de créer un sous-niveau dans lib (voire libs) pour différencier cette bibliothèque des autres. Dans notre cas, basique, ce n’est pas utile.
Note
[1] On voit souvent le nom vendors utilisé en lieu et place de lib/libs.
1 De Bernard -
Euh, j’ai pas compris ou???
Dans GitHub, le répertoire contenant la bibliothèque s’appelle /lib @ 9a47f67
et non pas /lib. Normal ?
2 De Franck -
Côté Github, cette indication @ 9a47f67 indique simplement le commit du dépôt cible (AccessConfig). Par contre quand tu travailles/récupères localement, le dossier se nomme lib, comme prévu.
3 De Franck -
Je précise que l’ajout de la bibliothèque se fait avec les outils de gestion de version, en l’occurence Git en ce qui nous concerne.
Cela dit, j’aurais tout aussi bien pu créer à la main le fichier .gitmodules à la racine et le dossier lib puis utiliser Git pour « charger » le contenu du sous-module à partir du dépôt distant.
4 De Bernard -
Si je comprends bien : les outils de gestion Git créent le fichier .gitmodules et “prépare” le dossier /lib @ 9a47f67 qui serait un “lien” vers la biblio Access42.
La mise à jour serait donc possible à chaque “récupération” locale…
D’où questions… ;-)
Je sais pas si je me fais bien comprendre, mais comme je travaille souvent “en local”, cette partie m’intrigue ;-)
5 De Franck -
Avec un outil comme SourceTree (que j’utilise depuis quelques années et qui est dispo sur Mac/Win/Linux) tu peux gérer tout ça, oui.
On peut aussi faire ça en « ligne de commande », via le terminal, mais c’est plus « chiant » je trouve, faut se souvenir de la syntaxe, toussa :-)
Sinon, on aurait tout aussi bien pu récupérer une copie de la bibliothèque et récupérer et installer les fichiers localement, sans lier quoi que ce soit avec leur dépôt sur Github. L’inconvénient est que si ils [Access42 ndla] modifient/corrigent quelque chose il faudra recommencer l’opération.
6 De Bernard -
bon, afin de mieux suivre la création du plugin je viens de télécharger la bibliothèque pour faire des tests en local et suivre point par point tes différents billets…
nb: j’ai pas encore utilisé SourceTree, car il faut, pour l’utiliser - si je comprends bien, créer un compte etc. Mébon, faudra que je me penche sur cette histoire, car, apparemment Github est utile quand on veut créer, par ex, des plugs ou des themes à partager ou créer/modifier en commun. Idéal, donc, pour la mise à jour des pugins et themes DC, is’nt it ? ;-)
7 De Franck -
Avoir un compte Github peut aider, en effet, par contre je ne suis pas certain qu’il faille un compte spécifique pour SourceTree.
Github peut aider pour le développement et la maintenance des plugins et thèmes, en effet, spécialement pour la gestion des tickets ;-)