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,
je dirais des devs puisque Composer ne s’adresse qu’à eux.