Re: Composer et SPIP sont dans un bateau

Hello,



Le jeu. 21 mars 2019 à 21:08, James <[email protected]> a écrit :

>
> Dans le contexte de la "première étape", c'est comme aujourd'hui :
>
> - Un plugin développé sur github qui est aussi configuré sur la zone avec
> une propriété externals + archive_externals.txt se trouve de fait
> installable via SVP.
>

Oui mais pour Plugins SPIP ça pose quelques problèmes actuellement pour
certains liens du plugin. Si on veut les multiplier il faudra résoudre
aussi ce problème.


> - Si ce même plugin est "composerisé", il pourra être installé avec
> composer en ligne de commande.
> - Un plugin géré sur la zone vit sa vie comme aujourd'hui.
>
> La question épineuse, c'est celle des dépendances de ce plugin :
>
> Les <necessite ...> les <utilise ...> du fichier paquet.xml seront
> toujours valide avec SVP tel qu'il est aujourd'hui, disons SVP 1.x, pour
> peu, bien sur, que les plugins nécessités soit sur plugins.spip.net. Je
> ne m'avance pas sur ce que SVP deviendra, c'est l'objet du chantier qu'on
> pourra appeler "SVP Composer compatible" ou "SVP 2.0".
>
> Un plugin "composerisé" avec des dépendances issues de l'écosystème PHP
> gérées par composer ne sera opérationnel que dans un contexte ou il sera
> installé en ligne de commande (toujours dans le contexte de la *première
> étape*), il sera inutile de le pousser dans SVP 1.x.
>

Oui mais si c'est le cas on n'aura plus la possibilité de référencer sur
Plugins SPIP.
SVP et Smart-paquets sert au zips et à l'installation mais aussi à Plugins
SPIP qui à mon avis est très utile dans la galaxie SPIP actuellement.


>
> Un plugin qui embarque des dépendances dans un sous-répertoire (vendor/ à
> coté de paquet.xml+composer.json) sur la zone ou ou sur github, ça devient
> imprédictible si on veut qu'il soit installable avec les 2 méthodes. Ça
> marchera surement pour SVP 1.x et probablement pas en ligne de commande. Je
> comprends les gens qui font comme ça, mais franchement, ça devra être les
> premiers trucs à faire corriger aux mainteneurs de ce genre de plugins; ils
> auront certainement un choix à faire, hélas. Heureusement, ils ne sont pas
> très nombreux. :-)
>

Ils sont peu nombreux.
Il faudra décider oui.
Le souci c'est que ce ne sont pas des plugins dist. Enfin YAML pourrait
l'être d'ailleurs....


>
> Le chantier "SVP Composer compatible" devra tenir compte de plusieurs
> problèmes techniques et de sécurité qui sont en partie déjà identifiés.
> J'hésite à entrer dans les détails, parce que je ne veux perdre personne
> (:D) avec de la technique, mais pourtant il va bien falloir s'y mettre. Y a
> rien de magique et tant qu'il n'y aura qu'un trop petit nombre de
> producteurices de code au sein de la communauté, qui expérimentent
> composer, se sera très compliqué et très lent. La *première étape* aidera
> peut-être à dédramatiser l'outil.
>

Je ne comprends ce que tu veux dire.
Pourquoi faut -il beaucoup de plugins sous Composer pour traiter le sujet ?


>
> À titre personnel, ça ne me choque pas particulièrement de faire coexister
> les 2 modes avec les risques d'incompatibilité que cela entraine pour un
> certain temps. Ces risques d'incompatibilités seront du fait et de la
> responsabilité d'un tout petit nombre de plugins facile à identifier. Mais
> pour que ce temps de cohabitation soit le plus court possible, on devra
> paralléliser des chantiers, SVP 2.0 étant celui qui sera, malgré tout, le
> plus long je pense.
>
>
C'est quoi dure pas longtemps dans SPIP ?

++
Eric