Re: Composer et SPIP sont dans un bateau

Le jeu. 21 mars 2019 à 19:35, Maïeul Rouquette <[email protected]> a
écrit :

> J'ai encore une question technique
> "Celleux qui activent des plugins depuis l'espace privé sans jamais
> > toucher une ligne de PHP ne verront pas la différence."
>
> Là je ne comprend pas si le fait qu'un plugin soit géré avec git +
> composer empechera qu'il soit distribué par ailleurs avec SVP. Puisque,
> à ma connaissance, nous n'avons pas encore de passerelle composer ->
> SVP.
>
>
Je vais faire plusieurs réponses, j'espère que je ne vais embrouiller
personne :

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

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

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.

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

Amitiés
>
> Maïeul
>
>
Amitiés,
-- 
James