Il concerne aujourd’hui le plugin archiviste, qui était déjà « prêt » à être packagé de la sorte et l’écran de sécurité.
2 PR sont en cours de développement :
Pour SPIP, configuré pour trouver les packages SPIP
Pour l’écran de sécurité, qu’on rend éligible au packaging par composer
Il y a encore un peu de travail et de discussion pour déterminer jusqu’où on va pour ce premier pas. Si vous êtes intéressé·e par ce chantier, pensez à suivre ces PRs
Si vous faites une mise à jour de type git pull sur la branche master, vous remarquerez que l’écran de sécurité n’est plus « doublement » versionné dans la branche master de SPIP. Il est uniquement dans son dépôt git dédié dorénavant.
supprimez le dossier plugins-dist/archiviste
exécutez composer install
Normalement, l’écran de sécu est de retour à sa place, et le plugin archiviste est dans plugins-dist/spip/archiviste.
Attention donc aux changements de branche master/4.2/4.1 sur spip/spip. Les fichiers composer.json/composer.lock changent en plus des changements décrit ci-dessus.
Nous allons procéder à des changements similaires pour d’autres plugins-dist dans un futur proches, mais avant cela, la branche master doit passer en 5.0-dev, et php mini 8.1+. Cf le teaser plus haut.
Je suis un peu de loin, mais c’est super de voir ces 1er pas concrets vers composer.
Pour tester j’ai mis à jour une install locale, tout s’est bien passé après avoir mis à jour composer lui-même en v2.5.x (j’avais une vieille version 2.1.x qui ne passait pas).
À moyen terme l’idée serait de passer tous les plugins-dist en packages composer ? Ou juste une partie dans un 1er temps ?
Nickel, merci ! Bon tant qu’on sera encore dans un entre-deux, il faudra vraiment penser à intégrer ces commandes supplémentaires à lancer (et les suppressions des anciens dossiers si possible) dans la commande spip-cli « core:telecharger » (alias « dl »), pour pas avoir à manipuler en plus. Mais bon ya déjà un ticket là dessus : #56 - executer composer: install à la fin d0un core:install - spip-cli - SPIP on GIT
Oui, c’est une des idées que nous avons. Ce n’est pas complexe mais ça demande un peu de coordinations :
soit on prépare tous les plugins-dist et le squelette « dist » en même temps, ça fait autant de PR + 1 pour les intégrer à SPIP en une seule fois.
soit on les prépare un par un et on fait une PR à chaque fois dans SPIP.
Cela demande aussi quelques autres opérations. Bref, on va organiser ça sous peu je pense.
Il est probable que « safehtml » demande plus de boulot. Il embarque des packages PHP, j’en profiterai bien pour les sortir du dépôt git. Y a un petit risque si je le fais en même temps, faut voir.
Autre chose, archiviste et safehtml présentent aussi la particularité de ne fournir que du PHP et nous sommes tentés d’en faire des « pures » packages composer. Archiviste est même totalement indépendant de SPIP. Pour Safehtml, il faudra mesurer l’impact des fonctions de SPIP (son API technique en quelques sortes) utilisées dedans.
Mais c’est un autre sujet
Toujours si vous faites une mise à jour de type git pull sur la branche master, le fichier plugins-dist.json a disparu. Normalement, les outils comme checkout gèrent correctement l’absence de ce fichier. À vérifier…
La suite :
Vider le cache
supprimer le dossier plugins-dist
exécutez composer install
Normalement, les plugins sont dans plugins-dist/spip
Concernant les noms des packages, je suis resté fidèle à l’idée de les faire coïncider avec les prefix des fichiers paquet.xml, ce que nous avions mis en œuvre à l’époque de la maquette SPIPRemix et de remplacer les _ par des -. Quelques renommages de dossiers, donc :
filtres_images devient images
porte_plume devient porte-plume
statistiques devient stats
textwheel devient tw
urls_etendues devient urls
Cas particulier : spip/dist est toujours mis à jour dans squelettes-dist
Nous avons fait le choix de ne pas transformer le code des plugins-dist, notamment ceux dans lesquels existent déjà des classes PHP et des lib pouvant être externalisées dans le dossier vendor/. Ces chantiers viendront par la suite.
Génial toutes ces avancées.
Je me pose quelques questions néanmoins afin d’appréhender ce nouvel environnement:
Je travaille principalement mes plugins sur la versions de dev de spip (le master). Pour spip 5, la version de dev est composer + PHP 8.1 si j’ai bien compris.
Pour les plugins, je fais pareil, la version de dev est le master, les versions précédentes sont nommées v0, v1… mais sont plutôt des anciennes versions c’est à dire que le master de mes plugins génère toujours des tags à jour (multiversions spip).
Si je veux adapter ou profiter de PHP 8.1 et de composer sur ces mêmes plugins j’ai l’impression qu’on va avoir un souci si je continue ainsi.
J’envisage donc de stocker le master actuel en vn et de réserver le master à spip 5 uniquement.
Mais de fait, sauf bug, je ne vais plus faire évoluer la version vn.
Est-ce que je me fourvoie ou y a-t-il une autre solution ?
Ne faut-il pas définir une stratégie commune pour les plugins en spip 5 ?
Ce qu’il faut retenir pour l’instant, c’est que nous nous sommes limités à SPIP et aux plugins-dist+squelettes-dist+ecran de sécurité. L’objectif étant, pour cette étape, d’améliorer et de faciliter la fabrication des releases de SPIP5, et dans la mesure du possible pour le développement en local, mais dans la limite de SPIP et ses plugins-dist.
Je suis heureux de voir que ça donne envie, mais en l’état actuel, ce que nous avons mis en place ne nous permet pas encore d’utiliser composer pour le développement et la distribution des plugins « non-dist » et nous ne pouvons pas dire quand et comment ce sera possible.
Bref, on y travaille et nous allons créer de nouveaux sujets pour parler de tout cela dans les semaines à venir.
Tout de même, pour te répondre, je pense qu’il n’y a pas besoin de définir une stratégie commune pour « composeriser » des plugins dans le futur, si ce n’est d’adopter le fonctionnement de base de composer :
Les branches git représentent soit une branche de maintenance soit un développement en cours. On différencie les branches de maintenance des autres, notamment parce qu’elles représentent, via un nom de type X.Y, l’état le plus stable d’une ancienne « famille de versions ». Il est souhaitable, mais pas nécessaire, de supprimer les branches de développement quand elles sont mergées, et de ne supprimer les branches de maintenance que lorsqu’on arrête, justement, de maintenir une X.Y.
Une de ces branches peut représenter l’état le plus stable du développement de la « famille de versions » la plus récente d’un plugin. Bien souvent c’est la branche par défaut du dépôt git et effectivement, sur gitea, c’est master qui est proposé.
Les tags qui respectent semver représentent des versions. (tout autres tags n’étant pas pris en compte par composer et les systèmes de distribution de packages associés). On peut donc les faire dans master ou dans une branche de maintenance si besoin.
Certains appellent ça le Trunk Based Development, je crois. Pour nous, le « trunk » étant la branche master, le tout est combiné avec quelques règles de semantic versionning.
En résumé, ce que tu décris pour tes plugins me semble assez proches de ça, les plugins-dist, quant à eux, suivant déjà globalement ce principe. À la vérité, composer ne fait que s’appuyer sur des « bonnes pratiques » déjà répandues dans l’écosystème PHP, bien avant git (cf le « standard layout » de subversion) et que nous avions déjà adopté pour spip.
Nous venons d’introduire pour la branche master de SPIP quelques nouveautés :
La mise à jour de l’écran de sécu devient automatique, plus besoin de configurer des scripts dans composer.json
Une commande composer local <command> qui permet d’exécuter des commandes composer en se basant sur un fichier composer.local.json (il le génère la première fois, s’il n’existe pas). Exemple: composer local require --dev rector/rector
Une commande composer local mode-dev qui transforme les urls https en ssh pour les plugins-dist. Attention c’est interactif.
Quelques explications rapides :
composer local est une astuce pour travailler avec un autre fichier que celui de composer par défaut. Il faut que cet autre fichier existe, sinon, ça pète, c’est pourquoi composer local <command> copie le fichier par défaut composer.json la première fois. Les fichiers composer ne se mergent pas et les plugins qui le proposent sont incomplets…
Sans cette commande, il faudrait créer soit-même le fichier local et faire COMPOSER=composer.local.json composer truc ... tout le temps.
composer local install installe les dépendances en se basant sur le fichier local.
Au final :
composer truc ... fait le job avec le fichier par défaut composer.json (versionné dans spip)
composer local truc ... fait le job mais avec le fichier personnalisé (non-versionné dans spip)
Pourquoi pas, même si les signets permettent à chacun⋅e de garder des fils au chaud. Amha, si c’est vraiment important on pourrait publier un petit billet sur le blog à ce sujet ?
Je pense qu’il faut le temps que ça mature avant de publier quelque chose. La version 5 est en chantier. On explore, et c’est sujet à changement encore.
Le truc intéressant pour les dev (mais pas indispensable non plus), c’est l’ajout de composer local mode-dev
Nouvelle étape : le dépôt composer est mis à jour automatiquement quand les dépôts git des plugins-dist reçoivent un nouveau commit, une nouvelle branche ou un nouveau tag.
Donc, composer local update spip/[PLUGIN] met à jour votre environnement de dev local quand il y a eu un merge dans la branche master de https://git.spip.net/spip/[PLUGIN]. C’est quasi instantanné.
Nous venons d’intégrer les tests unitaires du dépot spip/tests dans SPIP lui-même (voir https://git.spip.net/spip/spip/pulls/5581). phpunit devient une dépendance de dev de spip/spip. Il n’est donc plus nécessaire de conserver le dossier ./tests à la racine de votre installation locale.
Il reste à ce jour 3 PRs à reporter dans SPIP. À la suite de quoi pourra se poser la question du devenir de ce dépôt git (archivage, suppression, maintien pour SPIP4.2 ?)
