Re: Composer et SPIP sont dans un bateau

Salut les amis,

Pour rappel, alors qu'on ne parle de Composer que depuis un an sur cette
liste, et alors que cet outil n'a toujours pas été introduit en tant
qu'outil de développement pour celleux qui produisent du code dans le CMS
SPIP, ce projet PERD des utilisateurs.
Ceci depuis au moins 6 ans.
Pas besoin de composer pour ça.

Pour certains d'entre nous, c'est un sujet d'inquiétude, pour d'autres,
c'est un faux problème. Pour d'autres encore, ce n'est même pas un fait
entendable ...

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)

Ensuite, pour rappel toujours, à propos de la disparation de l'interface
graphique d'ajout de plugins : Il n'en a jamais été question.
C'est tout. C'est simple. Personne n'a annoncé que SVP allait disparaître.
Personne n'a dit qu'on allait contraindre des utilisateurs ayant peu de
compétences informatiques à taper des lignes de commandes. Il est aussi
tout à fait abusif de laisser entendre que des membres de la team
envisagent d'en faire le système par défaut de tous les utilisateurs de
SPIP.

Arrêtons les fantasmes un instant, s'il vous plaît.

On évoque en toute transparence, depuis un an maintenant, que le chantier
sera difficile et que ça demande donc de se faire une sorte de roadmap avec
des jalons.

On se fixe comme *première étape* de transformer le bloc de base (le core,
ses plugins-dist, son squelettes-dist et l'écran de sécurité) en une liste
exhaustive de composants assemblables par composer pour produire EXACTEMENT
un SPIP classique. La maquette SpipRemix présentée l'an dernier sur cette
liste rempli cet objectif. Pour cette étape, on ne parle pas de la zone, On
ne remet pas en question la manière de faire des plugins et des les
distribuer. Cela implique le maintien de SVP dans une distribution
classique de SPIP, le maintien de spip_loader, celui de files.spip.net, et
de plugins.spip.net, le maintien (pour les plugins de la zone, toujours) de
l'empaqueteur et des fichiers archivelist.txt, le maintien de salvatore, le
maintien de trad.spip.net, le maintien de subversion comme serveur de
gestion de version pour la zone... Tout reste. Rien ne bouge. Rassurés ? :-)

En gros, les changements seront les suivants : pour la distribution SPIP
classique, le bloc de base quoi, on n'utilisera plus l'empaqueteur pour
faire les zips. Les producteurices de code devront changer quelques
habitudes en passant de svn à composer et git. Notons ici qu'on passe de
l'usage d'un outil en ligne de commande à un ou deux autres et qu'il existe
des interfaces graphiques intégrées à des éditeurs de texte comme PHPStorm,
par exemple, mais aussi sublime-text, voir des clients lourds pour windows,
mac, etc. Je rappelle qu'on parle ici de personnes qui produisent du code
pour le bloc de base de SPIP.

Celleux qui produisent des plugins sur la zone pourront continuer sur la
zone, sans git, sans composer, avec svn, les fichiers archivelist.txt, etc.
S'ils le désirent, illes pourront essayer (et avec un peu de chance,
adopter), composer et git.

Celleux qui activent des plugins depuis l'espace privé sans jamais toucher
une ligne de PHP ne verront pas la différence.

Pendant ce temps, les développeurs et développeuses auront enfin le loisir
d’utiliser des outils de base "modernes" pour contribuer à SPIP.

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 :

- La classique, c'est celle que tout le monde connait et qui permet de
télécharger des plugins et de les activer depuis l'interface privée. Celle
qui s'installe avec spip_loader, et tout et tout. Mais qui pourra
aussi,alternativement, s'installer et se mettre à jour en ligne de commande
pour ceux qui le désirent.
- Un mini-spip, avec le moins de plugins-dist possible, voire un SPIP nu,
sans plugin du tout, pour servir de base à d'autres distributions, à
d'autres développements. Mais c'est une autre histoire.

La préoccupation principale semble être SVP. Soit. On vous accueille à bras
ouverts pour avancer sur le sujet.
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. Là, on aura besoin d'aide, de la patience et de la bienveillance
de la part de toute la communauté. Répondrez-vous présent ? Mettrez-vous la
main à la pâte ?

Amitiés,
-- 
James