Salut,
Après avoir introduit la possibilité d’utiliser composer dans la version de développement de SPIP5, et même s’il reste des travaux à faire dans les plugins-dist compresseur et safehtml (j’y reviendrai dans d’autres topics), nous avons pris le temps de réfléchir, avec @marcimat, à la possibilité de se servir des infos de composer pour gérer les versions et la compatibilité des plugins.
Pour permettre une transition douce, l’idée est de conserver l’existant (paquet.xml, svp) et donc, de ressortir ce vieux sujet d’il y a 2 ans : Et si on rendait les attributs version et etat optionnels dans la balise paquet des fichiers paquet.xml ? : Désormais, cette proposition peut évoluer pour rendre les attributs version, etat et compatibilite optionnelles dans les fichiers paquet.xml afin qu’il soit possible à un SPIP5 de traiter de la manière la plus transparente possible le cas où un plugin, dist ou pas, est « composerisé » ou non. À ce jour, on peut gérer les versions et les états avec composer, reste à traiter le cas de la compatibilité :
Si on refaisait aujourd’hui un recensement des fonctions de SPIP utilisées dans les plugins et qu’on poussait l’analyse plus loin que ce que j’avais fait à l’époque, il serait possible d’isoler une partie de ces fonctions dans (au moins) un nouveau package composer pour SPIP.
Supposons qu’on l’appelle spip/framework et qu’on sorte une version (stable) 5.0.0 et qu’il permette d’utiliser au moins une fonction très pratique include_spip() (ce n’est qu’un exemple, c’est un exercice de pensée). Il deviendrait alors assez simple d’ajouter ce package comme dépendance dans SPIP lui-même pour commencer : SPIP serait « compatible » avec le « framework » version 5, parce qu’il peut utiliser la fonction include_spip(). On ajoute cette même dépendance dans le plugin dist spip/bigup et ce dernier devient « compatible » avec le « framework » version 5, lui aussi. Bien sûr, un tel package pourra prendre en charge d’autres fonctions. C’est là tout le coté un peu « fastidieux » du chantier.
La gestion des plugins de SPIP devra dans ce cas lire les données techniques produites par composer pour afficher et traiter les infos de version dans l’admin en plus des données présentes dans les paquet.xml.
- On pourrait alors enlever les attributs concernées dans
spip/biguppuisque ce serait les infos composer qui serviraient alors. - Un plugin non-composerisé continuera d’indiquer ses infos dans son fichier paquet.xml avec les attributs historiques.
Je vais pousser du code expérimental dans une branche de spip et créer un nouveau dépôt git ce week-end et poursuivre les explications dans ce thread au fur et à mesure.
