SPIP BlogContexte
Composer est un système de téléchargement et mises à jour de dépendances, codé en PHP, développé par et pour la communauté PHP.
C’est l’équivalent de npm ou yarn en node.js. C’est devenu au fil des ans la référence pour intégrer facilement des bibliothèques de code PHP et gérer les diverses dépendances dans les projets PHP.
À ce titre, il est assez proche dans l’objectif des plugins SPIP (les bibliothèques / le code à partager) et de SVP (le gestionnaire de calcul et téléchargement de dépendances de SPIP) ; sauf qu’il est plus générique.
On en avait déjà parlé dans cet article.
Fonctionnement
Composer s’appuie sur un fichier composer.json (un peu l’équivalent de nos paquet.xml) pour déterminer ce qu’il doit installer.
Si ce fichier (ou une de ses dépendances) dit, « j’ai besoin de ’symfony/var-dumper’ à telle version », Composer (en simplifiant) cherchera les informations de ce paquet en requêtant le site Packagist (https://packagist.org/) qui fournit les descriptions des paquets publics connus (c’est un peu l’équivalent à plugins.spip.net chez nous). La description indiquera où trouver les zips (si disponibles) et les sources (git, svn, ...) du paquet demandé. Composer agira en fonction de ça pour télécharger ou mettre à jour si besoin le paquet demandé. Par défaut, tout est installé dans un répertoire nommé « vendor/ ».
Difficultés
- Composer par défaut, sans autre configuration, utilise le site Packagist.org. Ce site, qui utilise l’outil libre Packagist, ne sait obtenir les sources avec les zips que depuis github.com ou gitlab.com (ces instances là précisément).
- Composer pour calculer les versions à récupérer s’appuie sur le versionnement sémantique des branches et des tags sur les sources Git, Svn, etc. C’est la seconde difficulté pour nous (plus côté développeur/euses et migrations de code à réaliser).
- Composer fonctionne uniquement en ligne de commande. Depuis un terminal donc. C’est une des principales difficultés, pour la communauté SPIP que nous allons devoir affronter.
1) Packagist.org
Pour simplifier au maximum la transition vers Composer, on propose de déclarer les paquets SPIP (notamment le core, les plugins-dist) directement sur Packagist.org, et non pas dans une instance Packagist à nous. De la sorte, aucune configuration supplémentaire n’est nécessaire pour les utilisatrices ou utilisateurs. Mais cela implique de déposer les sources sur github.com ou gitlab.com.
On propose de déplacer le code SPIP (ainsi que les tickets) et les plugins-dist sur Github, en s’assurant d’avoir une sauvegarde des tickets et des repos Git.
2) Versionnement
Le versionnement doit s’appuyer sur https://semver.org/ pour les dépendances.
Pour le logiciel SPIP lui-même, on peut conserver une numérotation homogène où le changement de X dans x.y.z indique une étape forte dans l’évolution, sans forcément être exactement corrélé à semver.
Surtout, cela nécessite des repos Git ou Svn bien formés, où le numéro de version est indiqué dans la branche et les tags. Il faut donc reprendre l’historique svn et l’adapter, tout en le migrant sur Github pour qu’il dispose au moins de chaque branche (avec un composer.json dedans) et du dernier tag sur chaque branche.
On considère que les anciennes versions ne pourront pas être obtenues avec Composer (ça obligerait à insérer des fichiers composer.json tout en migrant l’historique, ce qui est passablement compliqué, pour un gain peu intéressant).
3) Terminal
Le problème du terminal est de loin le plus compliqué si l’on veut conserver une simplicité d’interface graphique pour nos utilisateurs, pour obtenir de nouvelles fonctionnalités sur leur site, sans passer par une développeur/euse.
Dans un premier temps
Pour le moment, nous proposons de distinguer le core + plugins-dist du reste.
Nous pouvons fournir, comme actuellement, une archive zip qui contient SPIP + ses plugins dist (et éventuellement un répertoire vendor/) pour les personnes n’ayant pas d’accès terminal pour installer SPIP. Les autres plugins seraient alors obtenus comme maintenant avec SVP.
Pour celleux ayant un terminal, l’installation de base n’est pas compliquée avec Composer. SVP continuerait de fournir les autres plugins.
Dans un second temps
Dans un second temps, il sera peut être bon de séparer en deux concepts :
- les plugins « composer », qui ne pourront s’installer que via Composer, mais qui peuvent déclarer du coup des dépendances à des librairies PHP via Composer.
- les plugins « interface », qui pourront s’installer avec SVP (ou Composer), mais qui ne devraient pas déclarer de dépendances (on ne saurait pas les télécharger via l’interface graphique SVP)
Le mélange des deux systèmes n’est cependant pas idéal. Mais il pourrait faire une transition douce entre les deux fonctionnements.
Dans un futur ?
Dans l’absolu, il ne devrait plus être considéré comme une obligation de fournir une interface graphique pour l’installation de plugins. Tout doit pouvoir s’installer en ligne de commande prioritairement.
Toutefois, pour les utilisateurs ayant besoin d’une interface graphique, il y a deux solutions qui restent à étudier (en utilisant uniquement Composer derrière) :
Calcul intégré et répertoire extensions/ (bolt.cm)
Bolt.cm, dispose d’une interface graphique pour gérer des installations de certains paquet Composer (leurs plugins pour Bolt). Bolt dispose de 2 répertoires
- le vendor/ habituel pour les installations normales avec Composer,
- extensions/ (avec des droits d’écriture pour le serveur web), qui est géré via une interface graphique (un peu comme plugins/auto donc) en utilisant des morceaux de Composer pour cela.
Nous n’avons pas étudié comment ils s’y prenaient pour pouvoir calculer les dépendances à télécharger sans disposer de beaucoup de mémoire PHP (ce n’est peut être tout simplement pas possible, et donc ça ne fonctionnerait peut être pas partout).
Calcul déporté (contao.org)
Contao a mis en place un outil de calcul des dépendances Composer en ligne pour eux. Et très récemment via un service (payant) pour d’autres communautés (https://composer-resolver.cloud/) (https://medium.com/@yanick.witschi/welcome-composer-resolver-cloud-30ebd4cb59fa). L’idée là est de déporter le calcul lourd des dépendences à obtenir, sur un autre serveur.
L’intégration graphique et la gestion ensuite des téléchargements n’est pas non plus anodine, mais c’est une autre piste possible.
Transition & priorités
Les « organisations », les « vendor »
Les paquets Composer sont nommés en utilisant 2 parties : vendor/name. Le vendor (minuscule) est le nom de l’organisation, du groupe de personnes en charge du maintien du paquet nommé name. Il pourrait y avoir un paquet "spip/core" où "spip" est le vendor, et "core" le nom.
Par convention, le même découpage est appliqué sur github.com ; on retrouverait l’organisation "spip", avec le dépot "core".
La question se pose du nom et des objectifs des organisations pour les plugins-dist et les plugins, actuellement enregistrés dans _core_ et _plugins_ ou _squelettes_ sur le dépôt SVN.
A minima, les plugins-dist devraient être migrés sur Github, mais dans quelle organisation ?
- l’organisation « spip » ?
- l’organisation « spip-zone » ? ou « friendsofspip » ou « copainsdespip »
- Quid des plugins-squelettes dans
_squelettes_? - On pourrait créer aussi plus d’organisations, avec des rôles et des responsabilités différentes. On n’attend pas par exemple le même suivi et revue de code sur un thème / squelette que sur les plugins du core, ou certains plugins spécifiques. Autrement dit, à certains endroits on préférera des PR [1] que des commits directs. Typiquement les squelettes qui fournissent différent thèmes pourraient avoir leur organisation dédiée.
Ce sont des choix à éclaircir et à décider.
Priorité 1
- Traduire les svn en git et les envoyer sur github.
- Ne pas gérer de synchro entre les deux. C’est du one shot.
- Le core et plugins dist dans l’organisation "spip".
- Déclarer l’ensemble sur Packagist.org
- Gérer le zip du SPIP obtenu via Composer, pour qu’il puisse fonctionner avec le spip_loader.
Priorité 2
- Migrer les tickets sur github. Mettre en place une sauvegarde régulière.
- Décisions sur les noms d’organisations des autres plugins (et plugins-dist).
- Déplacer certains plugins sur github.
Conclusion
Le chemin vers Composer est délicat à construire, mais nous semble indispensable néanmoins, afin de mieux s’articuler avec l’écosystème PHP.
Nous proposons aussi, une fois la base Composer présente, de séparer les développements de SPIP en deux parties (avec peut être 2 équipes distinctes) :
- Le Core (le noyau qui fait fonctionner la base de SPIP et ses plugins), que l’on souhaiterait faire évoluer pour profiter des capacités de Composer et l’intégration de librairies tierces,
- La distribution SPIP (un noyau + les plugins de base - comme aujourd’hui). Le noyau utilisé ne serait pas forcément le plus récent, ceci pour permettre une transition possiblement plus douce, et également pour ne pas freiner les évolutions du core. Cette distribution serait en charge de l’interface graphique (comme SVP actuellement).
Évidemment, les réflexions avancées ici peuvent être débattues [2] :)
Messages
18 mars 2019, 14:11, par guilaind
S’il faut passer par une ligne de commande, quelle lourdeur et quel retour au 19e siècle* !!!
Spip permet de ne pas avoir à mettre les mains dans le php et c’est une des raisons principales du choix fait par bon nombre d’utilisateurs/trices. S’il faut quand même mettre les mains dans une ligne de commande en ssh, avec les risques évidents d’une mauvaise manipulation terriblement facile à faire sous Linux, le temps aura raison de ces utilisateurs qui refusaient jusqu’alors de basculer vers un CMS type Wordpress où pour le coup, les maj sont faciles à exécuter depuis l’extranet.
Les 2 raisons sont :
Quand on voit la fréquence de maj de certains plugins comme saisies, c’est la sécurité globales des sites sous spip qui va devenir problématique car une maj sera synonyme de corvée au lieu d’un petit clic... et donc ne sera pas faite aussi souvent qu’elle devrait l’être.
Avec spip, j’ai pu faire une dizaine de sites de tous types dont un avec beaucoup de visites et plus de 15.000 urls sans toucher au php. Je dis : chapeau les gars et surtout merci d’avoir rendu cela possible !
* je sais bien que le web n’existait pas au 19e siècle :)
18 mars 2019, 14:29, par nicod_
Merci pour ce compte rendu, pour ceux qui n’ont pas pu venir (snif !).
18 mars 2019, 17:10, par RastaPopoulos
Pour ajouter des précisions : il y a eu et il y a toujours débat à l’intérieur de celleux qui étaient à cette formation.
Certaines personnes ne voyaient pas de problème majeur à ce que ça aboutisse par défaut à un système où on est obligé de payer un prestataire pour installer ou mettre à jour les plugins. En disant : si des gens ont vraiment besoin d’interface, qu’illes le codent en plus après coup. Mais donc c’est à la charge de celleux qui auraient vraiment besoin d’interface de monter un chantier pour coder cette fonctionnalité. Comme si ce public ayant besoin d’interface était le même ayant la capacité de dev de concevoir et coder cette fonctionnalité…
À l’inverse, d’autres personnes pensaient que pour le noyau/plugins-dist, du moment que spip_loader continue de fonctionner, ça ok on peut tout passer en Composer assez rapidement. Et ce point est à priori acté, on va avancer sur ça. Mais que pour les plugins, on ne peut pas se permettre d’aller vers Composer tant qu’on n’a pas déjà une solution qui continue de permettre aux gens d’installer par une interface.
Par ailleurs, ce problème d’interface n’est pas qu’une question technique, par rapport à un hébergement mutualisé pourri qui interdit l’accès à l’extérieur quand on est en SSH dessus (OVH mutu par ex…). Même sur un super serveur, il y a la question éditoriale : il y a de nombreux plugins qui peuvent être installés par les admins du site, en tant que choix éditorial, sans qu’il soit besoin de modifier les squelettes. Si un jour je veux faire des téléformulaires, ou si je veux restreindre l’accès à certaines branches de mon site, je DOIS pouvoir installer Formidable ou Accès Restreint, sans toucher du tout à de la technique, et encore moins en devant payer un prestataire pour ça : c’est un pur choix éditorial.
18 mars 2019, 18:16, par touti
C’était très bien cette formation, j’ai pas tout compris mais j’ai bien entendu que Composer va permettre à SPIP de simplifier la gestion de son développement en permettant à d’autres contributrices ou contributeurs de participer et vice versa.
Ainsi des librairies déjà éprouvées par d’autres communautés pourront être facilement intégrées et SPIP pourra partager son code plus facilement.
D’autre part, les plateformes de développement sont lourdes à maintenir (plus de 1000 plugins actuellement sur la zone), si l’on veut que le génial SPIP continue sa route sans se couper de sa capacité de partage, il est nécessaire d’appréhender rapidement un nouvel eco système, GIT, Composer, Librairies externes diverses, toujours dans l’idée de partager.
Non seulement les polatouches sont des touches à tout mais en plus ils volent bien plus loin que les écureuils et avec ce vent nouveau de Composer/GIT impulsé par @nicod et @james beaucoup de personnes reprennent gout et envie de voir continuer à voler leur animal favori.
Bien entendu, il faudra accompagner par une documentation soignée les utilisateurs et utilisatrices qui ont peur de taper trois lignes dans un terminal pour les rassurer sur toutes les facilités que cela amènera. On compte sur vous pour apprendre à voler !
18 mars 2019, 21:07, par spiploove
Bonjour
Cela fgait bientôt 10 ans que nous développons nos sites internet avec SPIP et je suis tombé par hasard sur votre article, pour être sincère je ne comprends rien à ce qui est dit et cela m’inquiète beaucoup, j’ai cherché de l’information sur le web concernant composer et je ne comprends toujours pas...
J’ai juste compris qu’il allait fallait peut être à terme prévoir de taper de la ligne de commande....
Une remarque concernant ce pré-requis, les hébergements mutu chez OVH que nous utilisons ne permettent pas dans l’offre « perso » de SSH...
Merci pour vos futures explications et de prendre en compte le niveau hétérogène de la communauté SPIP
MERCI
19 mars 2019, 10:16, par Ysabeau
Comme spiploove, je ne comprends absolument rien à cet article seulement qu’il va falloir installer des plugins en ligne de commande et là, je suis vraiment désolée, mais c’est pas possible.
On ne peut pas parler de la simplicité de SPIP et revenir à un système de lignes de commandes pour installer des plugins surtout avec la « pluginisation » quasi systématique des squelettes qui est là, d’ailleurs, pour faciliter la mise en place des sites.
Maintenant, si vous ne parlez que des plugins verrouillés, c’est autre chose.
19 mars 2019, 19:34, par JLuc
Ysabeau, rejoins la team interface !
19 mars 2019, 20:34, par Ysabeau
JLuc ? Pourquoi ?
20 mars 2019, 11:14, par JLuc
Pour garder une interface simple et sympa même avec Composer, si cette évolution se confirme, et contribuer à ce que le Spip avec interface-à-la-SVP-vers-Composer ne soit pas à la traîne par rapport aux futurs développements faits avec du noyau avec composer...
20 mars 2019, 12:24, par RastaPopoulos
Ça part un peu dans tous les sens, scusez.
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.
20 mars 2019, 14:52
Comment ?! Quoi !? Qu’ouïs-je ?! SPIP va devenir vendor ?! Mais où c’est qu’on peut acheter des actions ??
— >[ ]
22 mars 2019, 14:18, par Ysabeau
Je rejoins tout à fait Rastapopoulos dans cette histoire.
J’ajouterais que certains squelette, tel Escal ou Eva ont été développés par l’Éducation nationale ou des fonctionnaires de cette institution pour faciliter la mise en place et la gestion de sites internet par des gens qui ne sont pas des développeurs. Escal fait l’objet de mises à jour très fréquentes. Imposer une mise à jour par code en virant l’interface graphique serait tout simplement tuer ce genre d’initiatives. Et je ne parle même pas des problèmes de sécurité, ni même de la maintenance et du développement des plugins. Est-ce que les développeurs auront toujours envie de faire et de mettre à disposition des plugins pour une petite poignée de gens ?
Bref, ce serait la mort de SPIP.
En revanche :
Moi aussi.
22 mars 2019, 14:59, par nicod_
Je pense que le début du paragraphe Dans le futur est mal rédigé, il laisse libre cours à une interprétation et aux réactions (que je comprends) qu’il a suscitées, ici et ailleurs.
Je me permets de citer un extrait d’un mail de mise au point que James a envoyé sur la liste spip-dev :
25 mars 2019, 09:46, par Ysabeau
Merci Nicod.
Il faut admettre que ce paragraphe
Fiche un peu la trouille et que la priorité devrait rester à l’interface graphique et l’installation en ligne de commande une option et non l’inverse comme c’est écrit.
1er avril 2019, 02:14, par Zefyr
Pour information la communauté Drupal a également fait le saut Composer depuis quelques années et produit au passage des réflexions et outils qui pourraient être utiles à Spip, le projet Ludwig en est un example. Bon courage !
7 avril 2019, 11:23, par klaus++
Rastapopoulos dit :
7 avril 2019, 14:12, par RastaPopoulos
@Klaus euuuuuh qu’est-ce que tu racontes là ?
Composer c’est LE gestionnaire de paquets/dépendances de la communauté PHP, c’est le cœur de tout l’écosystème PHP depuis des années maintenant, pourquoi tu parles de JS ?
Et non le script dont tu parles n’a rien à voir, et il est justement pas en PHP mais écrit en Bash, et n’est pas conçu pour être extensible. SPIP-Cli à la limite si tu veux parler d’interface en ligne de commande, est écrit en PHP par contre, avec la même base que Composer justement, et permet d’ajouter des commandes à l’infini facilement.
Mais là on parle de s’intégrer directement dans l’écosystème PHP/Composer, ça n’a rien à voir avec juste utiliser une commande en terminal. On parle d’un gestionnaire de paquets et de dépendances, afin entre autre de pouvoir utiliser enfin des projets tiers, déjà maintenus par d’autres dans la communauté PHP.