Re: Composer et SPIP sont dans un bateau

Le 19/03/2019 à 14:58, [email protected] a écrit :
> Salut
>
> Merci pour ce retour.
> Je me permets 1 remarque et 1 question :
> La première personnelle, c'est ce choix de SASS avec github/gitlab par
> défaut. Je pense toujours que c'est une bêtise mais celui qui code qui
> a raison.

Il y avait plusieurs raisons discutées à cela, entre autres et avant 
tout car c’est plus simple pour Composer avec Packagist.org, et aussi le 
fait de s’éviter de la maintenance.

> La seconde si je comprends bien l'idée on aurait 2 zones de
> téléchargement distinctes une pour SVP et l'autre pour composer.

Distinguons d’abord la première partie du plan (core + plugins-dist). 
Celle-ci ne pose pas trop de problème il semblerait.
On aurait le zip habituel (avec peut être un vendor/ en plus selon ce 
qu’on utiliserait comme librairie de base), et le reste serait géré par 
SVP comme actuellement.

C’est la suite logique (mais un peu plus lointaine) qui est plus 
discutable (utiliser Composer aussi pour les autres plugins).
Effectivement, pendant un temps on se retrouverait avec 2 sortes de 
plugins,
- une capable d’être utilisée avec Composer,
- l’autre capable d’être utilisée avec SVP,
- et des plugins à l’intersection des deux

> Comment va se gérer la maintenance d'un plugin ? Un plugin installé
> par composer serait hors écosystème SVP (et pas réciproquement)
Assez probablement un plugin installé par composer (en terminal) ne 
pourrait pas être mis à jour par interface graphique (SVP ou un 
descendant de SVP utilisant une interface graphique avec Composer), quoi 
que je ne suis pas sûr que ça soit impossible.
>   cela
> me semble un coût important sans avancée notable. En l'état un plugin
> SVP n'a pas de vraie raison de passer en plugin Composer. Et un plugin
> composer sera restreint aux terminaux serveurs.

Oui, mais ce raisonnement se base sur les plugins actuels qui ne peuvent 
pas utiliser Composer actuellement ! (Ou qui tentent de le faire 
difficilement en fournissant eux-même un répertoire vendor/ ce qui a 
toutes les chances de péter… il y en a 3 comme ça sur la zone déjà). 
L’avancée, me semble-t-il, c’est justement de pouvoir récupérer et 
utiliser des librairies externes facilement. Et de faire évoluer nos 
plugins.

> [...]
> Là où je coince c'est le principe de la transition, à moyen/long terme
> je vois toujours 2 solutions à maintenir et non un remplacement, et
> cela du fait des contraintes propres à composer.
Oui. Et cette transition n’est pas encore très claire.
> Et donc je
> m'interroge sur l'intérêt de la bascule tant pour les développements
> que pour les usages des plugins .

Bah, on peut aussi apprendre à se contenter de ce qu’on a, après tout, 
ça fonctionne encore :)
Mais personnellement, ce grand écart en SPIP et le reste du monde PHP 
commence à me taper grave sur le système, alors je suis plutôt content 
de cette direction vers Composer.
Mais ça n’a pas l’air de satisfaire tellement ici au final. Peut être 
qu’on fait fausse route.

MM.





_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip