Pierre Andrews a écrit :
Avoir une methode automatique qui fait des paquetages des versions sur la zone, les mets dans un coin (/file/spip-zone) d'où on peut facilement pointer depuis un article pour les novices, ça simplifie déjà beaucoup.
Il me semble qu'il est intéressant que la méthode de génération automatique des paquets paquets.sh permette :
1) à court terme un téléchargement facile de chaque plugin au format zippé par des novices;
2) à un peu plus long terme une gestion automatique des paquets depuis un spip : génération en local d'une liste des paquets disponibles, des paquets téléchargés et des paquets activés, mise à jour automatisé des paquets.
Bon juste quelques idées pour reprendre un peu le concept de paquets à la debian et après avoir jeté un oeil sur paquet.sh (Connexion · GitLab) et le résultat Connexion · GitLab (où l'on trouve pour l'instant pèle mèle plugin individuel, lots de plugins, squelettes et autres).
Pour les 2 situations il faut prendre en considération l'état d'un paquet (dev, test, stable, experimental), son numéro de version (pas la version svn mais un numéro de version arbitraire qui ne change que suite à des modifications majeures d'autant qu'un commit peut être synonyme de régression) et la version de spip (1.9, 1.9.1, ...).
A partir de là on peut imaginer que la méthode automatique paquets.sh génère une arborescence de la forme :
- 1.9
|- dev
|- test
|- stable
|- experimental
- 1.9.1
|- dev
|- test
|- stable
|- experimental
Pour cela, une idée serait de rajouter dans plugin.xml des informations de versions de spip et de prendre en considération les fichiers plugin.xml dans la génération des paquets.
Par exemple :
<spip_version>1.9<spip_version>
<spip_version>1.9.1<spip_version>
[tant qu'à faire, on peut également ajouter un truc du genre <depend>Plugin1</depend> <depend>Plugin2</depend>]
Faire une charte des développeurs de plugins précisant qu'un nouveau paquet n'est généré que lors d'un changement d'état, de version et de spip_version, ce qui impose à modifier <version>, <etat> et <spip_version> pour déclencher un nouveau paquet.
L'idéal est de pouvoir générer plusieurs versions d'un même paquet (la release x svn déclarée stable génère un paquet alors que la release x+1 svn du même plugin peut être déclaré en test).
Cela complique paquets.sh puisqu'il faut regarder les plugins.xml et archiver nom, version, etat, spip_version dans une bd pour savoir si on génère ou non un nouveau paquet. En effet, un utilisateur final n'a pas besoin de mettre à jour ses plugins à chaque commit mais que suite à des changements majeurs ou corrigeant des bugs bloquants.
Concernant le 2), il est en outre nécessaire de séparer le plugin proprement dit de l'information concernant le plugin : son nom, sa version, son etat, la version spip, sa description, ceci pour permettre de récupérer via le net la liste de tous les plugins disponibles sans avoir à télécharger tous les plugins nécessaires (en résumé sortir le svn.revision du paquet) On peut imaginer alors de générer en local (soit en bd soit sous formes de fichiers xml dans plugins/) la liste des plugins disponibles (sorte de apt-cache update), la liste des plugins téléchargés en local (cache dpkg) et la liste des paquets installés.
A partir du moment où la caractérisation du paquet est sorti du zip, on a la possibilité de coder les fonctions permettant de collecter les infos à partir du dépot des paquets, de télécharger les paquets correspondant à sa version de zip et de les décompresser (ainsi que de mettre à jour lors d'un changement de version).
<disgression>
Exemple de fichiers xml dans le répertoire plugin que pourrait générer cette fonction (ou en bd mais c'est juste pour montrer l'idée).
paquets_disponibles.xml :
<plugin>
<nom>PluginTruc</nom>
<version>0.9</version>
<depend>Plugin1</depend>
<depend>Plugin2</depend>
</plugin>
<plugin>
<nom>PluginMachin</version>
<version>1.1</version>
</plugin>
...
paquets_actives.xml :
<plugin>
<nom>PluginTruc</nom>
<version>0.9</version>
</plugin>
...
sources.list :
http://plugins.spip.org
Tant qu'à faire autant pouvoir préciser un dépôt miroir (plus pratique à Bamakode télécharger la liste et les plugins depuis un miroir local proche situé à l'université plutôt qu'à des milliers de kilomètres).
</disgression>
Quant à savoir quand un paquet est jugé stable ou non ? Ici je pars du principe que c'est à la discrétion des commiters. On peut aller plus loin en affectant un mainteneur comme pour les paquets debian et d'associer un hash pour que ce ne soit pas quelqu'un d'autre que le commiter qui versionne mais ca parait quand même trop compliqué. Ou que plusieurs personnes de mainteneur décident du passage de test à stable mais une charte des développeurs de plugins précisant quelques règles communes devraient suffire.
La question des mises à jours automatiques par la suite n'est pas anodine car quand je vois toutes les vieilles versions de spip en production sur une plate-forme mutualisé d'hébergement, sans possibilité de mettre à jour facilement un plugin, x versions d'un même plugin peuvent se retrouver dans la nature (trop fastidieux de s'informer et de mettre à jour manuellement les plugins).
V'là pour quelques idées en vrac ... [je veux bien commencer un prototype de récupération de listes de plugins/téléchargement/décompactage de plugins à partir du moment où on peut disposer de la caractérisation des plugins en dehors des paquets 
]
Amicalement,
Philippe
Note : super les articles http://www.spip.net/fr_article3448.html et http://doc.spip.org/@Tuto-Se-servir-des-points-d-entree !
Maintenant, si se script préremplis une DB, avec la version du plugin, son paquetage, etc... etc... alors il y aura déjà un minimum d'info disponible pour faire un site de distribution des paquetages fini. Avant même que les devs écrive un article à propos.
Pierre
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
) et mis à disposition dans un espace plus approprié pour les gentils utilisateurs.