Re: Changer la gestion des catégories de pl ugin

Hello,


Le dim. 19 mai 2019 à 10:23, Matthieu Marcillaud <[email protected]> a
écrit :

> 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.

++
Eric