Hello,
On se place dans un moment charnière où il y aurait des plugins SPIP
«composerisés», mais pas tous. L’idée (de ce que j’ai compris) qu’il
avait en tête en refaisant Smart Paquets est de changer à terme la
méthode de déclaration des paquets (actuellement archivelist*) pour :
- un automatisme pour les plugins Composerisés (présents sur Packagist)
: une API publique à Packagist permet de lister l’ensemble des paquets
de type “spip-plugin” par exemple
(https://packagist.org/packages/list.json?type=spip-plugin). À partir de
cela il est possible de récupérer une description de chaque paquet (dont
le nom, la source, l’url de documentation, le zip …)
(https://repo.packagist.org/p/spipremix/saisies.json). Donc, de notre
côté, avec un petit cron, il semble possible de découvrir
automatiquement ces plugins SPIP pour les lister dans cet annuaire.
Faut juste penser que smart-paquets ne fait pas que compiler les données contenues dans un paquet.xml ou un plugin.xml. Il construit des données incluses dans le archives.xml comme les traductions.
Donc je ne sais pas comment une API sur un outil qui nous est externe et sur lequel nous n’avons pas prise peut arriver à rendre un service équivalent. C’est à étudier, je le répète depuis des semaines sans être audible il semblerait, Composer me parait indolore dans l’étape initiale sauf pour le référencement des plugins et c’est pour cela que j’ai lancé les deux derniers fils.
Ca serait donc bien que cette réflexion se fasse plus ouvertement car je sais par expérience que les fonctions de SVP, ses modules connexes et smart-paquets sont mal connues.
- pour les autres plugins, l’idée serait d’avoir sur plugins.spip.net un
formulaire où l’on saisit l’url du projet (plutôt que de donner l’url du
répertoire à zipper avec le n° de commit) : de donner l’url racine du
projet (le git), ou sur la zone, le svn au niveau de la racine d’un
plugin (plugins/saisies) en standard layout (tags / branches / trunk)
et c’est l’outil qui génère alors un zip pour chaque tag, branche, trunk
(lorsque la forge ne fournit pas d’api pour obtenir le zip) ; Donc sans
indication de révision spécifique.
Je comprends pas le “sans révision spécifique”.
Si je comprends bien c’est une autre façon de construire le archivelist.txt non ?
Dans le chantier Refonte de Contrib, qui permettra de construire un nouveau référentiel des plugins (Plugins SPIP + Contrib) on a prévu :
- un workflow “documenter un plugin”
- puis ensuite, hier, on s’est dit qu’on pourrait avoir un workflow “catégoriser un plugin” qui pourrait se prolonger par le précédent.
- j’ai l’impression que là on pourrait encore faire un pas de plus en ayant un workflow “déclarer un plugin” qui pourrait être un préalable ou englober les deux précédents workflows.
- en allant (beaucoup) plus loin, dans ce cadre de la zone, cet outil
pourrait servir à transformer des plugins non standard layout sur la
zone en standard layout, voire faire la migration svn > git, pour les
personnes donc qui ne sont pas à l’aise avec ces migrations.
Why not c’est une bonne idée.
Par rapport aux documentations
Je pense qu’il faut aussi tenir compte des fichiers ‘Readme.md’ qui est
relativement standard lorsqu’un code source est mis sur github. Assez
souvent aussi un répertoire doc/ ou docs/ est présent. Mais dans la
mesure du possible, s’il y a un composer.json, l’url de documentation
est indiquée (de même que s’il y a un paquet.xml).Pourquoi demander (lorsqu’on déclare un plugin) de rédiger autre chose
si une telle url est renseignée ? Enfin ça mange pas de pain, mais à mon
avis il manque “La documentation existe déjà” dans les choix.
Absolument. Mais on a déjà ce cas actuellement puisque qu’une partie de la doc des plugins est rédigée en dehors de Contrib et pointée par le lien “documentation”.
Maintenant, je trouve que ce n’est pas une bonne idée parce que le suivi éditorial de Contrib permet d’avoir une documentation relativement homogène et de qualité, ce qui n’est pas le cas des readme que j’ai pu lire, loin de là…
Donc c’est possible mais je trouve que ce n’est pas à encourager.
