Re: Composer et SPIP sont dans un bateau

Je vais éviter de répondre quatre fois en créant autant de branches dans
le fil, et essayer de regrouper des réponses à Matthieu, James, Eric…

Le 20/03/2019 à 13:25, Matthieu Marcillaud a écrit :
> Et de temps à y consacrer

Ça c'est pas propre à l'interface pour composer mais à n'importe quel
gros chantier (refonte admin, refonte spip.net et docs, etc). On sait
bien qu'on n'en a pas des masses quelque soit le sujet (alors plusieurs
sujets à la fois…).

> Des plugins ou tous les plugins ? 

Potentiellement tous puisque la majorité ont des dépendances, et pareil
pour les squelettes partagés (tous dépendent de nombreux plugins) et
parfois même pour les thèmes (scss, bootstrap ou autre). Donc si un
plugin nécessité est fait en Composer afin de lui-même nécessiter une
lib (yaml, etc), et bien tous les plugins et squelettes qui en dépendent
devront pouvoir trouver et installer ces dépendances en même temps par
l'interface aussi. Donc oui, très probablement tous les plugins.

Il n'y a donc pas de demi-mesure possible. Et je vois mal comment il
pourrait y avoir de transition avec les deux systèmes à la fois.

Scénario (très) crédible :
- Touti développe un plugin avec Composer qui nécessite une lib, ce
n'est donc installable que par Composer
- Charles développe un squelette générique, totalement destiné aux
end-users donc, qui doivent pouvoir le choisir dans leur site, et ce
squelette nécessite le plugin de Touti (et 15 autres dont plusieurs
peuvent être en Composer)
- Jean-Michel Admin a lu la doc du super squelette configurable de
Charles et le trouve génial, il décide donc de l'installer sur son site
(sur lequel il n'a pas la main techniquement, ou bien il a un mutu sans
accès à l'extérieur). Jean-Michel DOIT pouvoir trouver et installer le
squelette ET tous les plugins dont il dépend (et toutes les libs vendor/
dont eux-mêmes dépendent).

Si tu veux donc "profiter de Composer" pour ton petit plaisir personnel
de dev ok, c'est compréhensible, mais donc faut bien être conscient que
ça ne sera utilisable QUE par les prestataires de service.

> Tout est hypothétique… même le fait de perdre N% des utilisateurices… qui seraient déjà partis de toutes façon pour plein d’autres bonnes raisons… 

Totalement en désaccord pour ce point. Et là ça rejoint des réponses à
d'autres plus loin dans la discussion.

James a écrit :
> Si ça vous inquiète vraiment, parlons-en, cherchons des solutions. Cherchons alors à comprendre pourquoi on perd aujourd'hui des utilisateurs alors que rien n'a vraiment bougé sur le plan technique depuis ... allez, disons une dizaine d'années... (et je ne fais aucun sous-entendu ni de reproche)


Utilisateurices tout court ça ne veut rien dire, et j'ai bien fait des
distinctions précédemment.

Les gens qui sont des utilisateurices au sens "utilisateurices d'un
framework", bah s'illes veulent vraiment un framework, illes vont
utiliser ce qui est réellement conçu pour ça (laravel, symfony etc).

Je ne crois absolument pas qu'on va amener des gens à SPIP parce qu'on
se mettrait à faire du Composer. Allez pour être gentil, une ou deux
personnes à la marge.

Pour les utilisateurices au sens "intégrateurices, du dimanche, ou pro,
mais pas énorme" : il n'y a RIEN d'hypothétique, là on a eu noir sur
blanc des réactions sur le blog, les réseaux sociaux, etc, que si pas
d'interface, on les perdait. Alors je n'en sais rien de la quantité,
d'où le N%, mais dans un cas on est sûr de perdre des gens, et dans
l'autre ya aucune sorte d'indice qui laisserait penser qu'on en
gagnerait *pour cette raison*.

Pour les utilisateurices au sens "end-users de l'interface, admins,
rédacs", là encore moins. S'illes ne peuvent plus installer Accès
Restreint ou Formidable sans faire appel à un⋅e tech.

La raison principale pour laquelle on va passer en Composer (pour moi
c'est acté), c'est pour que les gens *déjà actifs* puissent utiliser des
projets tierces, afin d'arrêter de tout maintenir nous-mêmes,
d'économiser nos forces, et nous concentrer sur ce qu'on veut vraiment
apporter et améliorer dans SPIP.

Cela touchera donc les end-users, mais de manière indirecte, en ayant un
peu plus de temps et d'esprit libre pour des choses plus importantes que
les morceaux que d'autres ont codé mieux que nous ailleurs (et mieux
maintenus).

Je suis pour ma part totalement d'accord avec Éric, ce qui fait qu'on
perd des gens, c'est surtout que ça n'a pas bougé depuis 10 ans au
niveau ergonomique, et pour certaines fonctionnalités majeures qui sont
maintenant partout ailleurs (constructions par blocs, vrai
multi-domaines, etc). Et ce point pour le coup vaut d'abord pour les
end-users mais AUSSI pour les devs et intés : c'est parce qu'un logiciel
est assez utilisé, aimé, plébiscité, et ça encore mieux dans plusieurs
domaines différents (assos, militants, collectivités, musées, médias,
etc) que du coup il y a des dévs et intés qui vont vouloir/devoir
travailler avec, puis dessus.

Attention je ne confonds pas : oui quand on part de zéro, de la base, on
peut faire un truc avant tout destiné aux devs, qui font ensuite décider
de l'utiliser pour les fondations d'un truc plus gros qui sera pour des
end-users. Mais là on parle de SPIP. D'un CMS "produit final" pour les
gens qui écrivent et publient. C'est donc avant tout ce public là qu'il
faut aider et chérir pour espérer augmenter les dévs.

> Passons cette première étape et pour que tous les chantiers qui s'en suivront ne se bloquent pas les uns les autres, on propose de fournir non pas une distribution de SPIP, mais deux :

C'est une expérience de pensée intéressante :), mais au niveau concret,
ça aboutit à une balkanisation des plugins puisque de fait le principal
but est dans la phrase juste avant :
> Pendant ce temps, les développeurs et développeuses auront enfin le loisir d’utiliser des outils de base "modernes" pour contribuer à SPIP.

Et que donc dès qu'un plugin nécessitera un projet tiers de l'écosystème
PHP, il ne pourra s'installer qu'avec Composer, et que donc sans
interface dès le début de prévu… bah impossible d'avoir une seule
communauté unie. Cf le détail plus haut dans la réponse à Matthieu dès
qu'il y a des dépendances (y compris dans un squelettes donc).

> La préoccupation principale semble être SVP. Soit. On vous accueille à bras ouverts pour avancer sur le sujet.

Oui, c'est bien tout l'objet de la discussion (pour moi). Je ne
m'inquiète absolument pas du noyau, de la dist.

Et donc c'est contradictoire avec :
> Personne n'a annoncé que SVP allait disparaître. Arrêtons les fantasmes un instant, s'il vous plaît.

C'est bien dit pour rassurer, mais concrètement… non, on n'a pour
l'instant pas de solution sous la main pour trouver et installer les
plugins (je parle bien uniquement des plugins) qui de plus en plus vont
se mettre à nécessiter des projets tiers (donc plus installables par
SVP). Cf encore le scénario très basique et commun décrit plus haut. Et
tu le dis de toute façon toi-même dans le mail suivant.

Et comme dit plus haut, je ne vois pas comment ça pourrait cohabiter.

> Mais le vrai problème urgent qui vient, c'est qu'il y aura nécessité à changer le fonctionnement de trad.spip.net pour fonctionner avec git et composer
Oui, et ça on en a besoin dès le core…

Je n'en sais rien de l'ampleur (jamais regardé le code de trad.spip et
salvatore), mais si de toute façon il faut recoder des choses, je me
demande tout haut si on ne devrait pas aller vers du format standard
côté trad, quand bien même ensuite un script retransformerait tout en
format SPIP machin_fr.php (qui sont surchargeables, fusionnables etc).

Ça permettrait peut-être de ne plus avoir à maintenir une appli dédiée
trad.spip, avec ses tables, etc. Mais bon je dis ça à l'arrache, si
c'est "juste" que salvatore puisse pusher vers les différents Git,
peut-être que c'est trop différent en temps pour que ça vaille le coup.

Pouet, dodooooo :(

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