Re: Composer et SPIP sont dans un bateau

Je copie un de mes coms du blogs (obligé puisque répondant à des gens là
bas).


1) Historiquement, la ligne de commande n'est pas un retour en arrière,
ça dépend complètement de quels publics on parle. La ligne de commande a
toujours été et est *plus que jamais* l'outil de base des
développeur⋅euses, et depuis quelques années tout autant des
intégrateurices. Tous les projets PHP de nos jours s'installent avec
Composer, et la majorité des outils d'intégrations (frameworks JS, CSS
etc) s'utilisent en ligne de commande avec l'écosystème Javascript NPM.
Et cela vaut aussi bien pour les devs/inté lors de la construction d'un
site/d'une appli que pour celleux qui déploient et maintiennent les
choses en ligne (les admins sys). Quand on dit "outils modernes" dans le
monde du dev et de l'inté, c'est justement que des trucs en ligne de
commande.
*MAIS* ça c'est pour le monde "super pro", moyen et gros projets, où il
y a des compétences très découpées. Il n'en reste pas moins qu'il
continue d'y avoir de nombreuses intégrateurices (et même parfois des
boites de plusieurs personnes !) qui ne font que de l'intégration
classique de base, et qui utilisent SPIP depuis des années uniquement en
interface pour l'installer et le maintenir chez leurs clients.
(M'est-avis que ce public se réduit d'année en année tout de même.)
Ainsi que des utilisateurices associations, site perso, PME ou autre,
qui font tout en interne, en bidouillant. Si on veut garder ces publics,
les interfaces doivent exister que ce soit pour l'installation de SPIP
(ce sera toujours ok avec spip_loader on a dit donc stop) ET des plugins
(c'est là le truc compliqué).

2) Quand on parle d'interface pour Composer, il s'agit d'un chantier
purement de devs, de code, de délégation de système, d'admin sys. C'est
ça le truc à résoudre. Pour l'ergonomie ça n'a strictement aucun rapport
avec cette discussion. Au pire ça peut rester sensiblement pareil
visuellement, et au mieux ça à un rapport avec un chantier de refonte
ergo de l'admin. Donc pour ce chantier précis là, on n'a (pour
l'instant) pas besoin de compétence en ergonomie ou en intégration, ce
n'est pas le cœur du problème.

3) Comme je l'ai déjà dit précédemment, il ne faut pas rester que sur
cette différence entre "méga pro moderne" et "simple inté" ou
"bidouilleureuse". En effet, même pour des sites qui auraient été
développés par une grosse équipe avec des outils modernes ET mis en
ligne par des admins sys avec des outils modernes : les plugins DOIVENT
pouvoir être cherchés et installés par une interface, car de nombreux
plugins sont des *choix éditoriaux* qui peuvent donc être faits par des
admins (au sens SPIP) sans aucun rapport avec la technique.

Bref, mon avis général est que pour noyau, on est bon. Mais que pour les
plugins, on ne doit pas aller vers Composer tant qu'on n'a pas déjà une
interface utilisable sous la main. Pour *aucun plugin*, car de toute
façon ils se nécessitent tous les uns les autres, et les squelettes
génériques partagés nécessitent tous aussi des plugins fonctionnels.

On ne peut pas perdre de manière certaines N% des utilisateurices pour
un gain qui lui est seulement hypothétique.
Attention : le gain pour les quelques devs de SPIP qui vont pouvoir
s'amuser à nécessiter des libs externes est sûr à 100% mais illes se
comptent sur les doigts des mains ! En revanche le gain de nouveaux
utilisateurices qui viendraient parce qu'on serait en Composer, lui est
totalement hypothétique.

Si on dit "SPIP doit *permettre* de ne pas avoir d'interface pour
installer et mettre à jour", je suis totalement d'accord ! Sauf que si
on dit que pour l'instant on part là-dessus sans en avoir et que c'est
aux gens qui en ont besoin de le développer plus tard, ça n'a rien à
voir ! Là ce n'est plus permettre, c'est *obliger* à ne pas avoir
d'interface, et rendre hypothétique l'arrivée d'une interface plus tard.
Ça n'a donc rien à avoir avec la phrase de départ. (Et je suis contre.)


-- 
RastaPopoulos

_______________________________________________
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