Bonjour @JamesRezo et merci !
ca fonctionne bien !
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 ?
(y) c’est beau…
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
1 « J'aime »
Merci pour vos encouragements 
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 
Salut,
Voici le second pas.
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.
1 « J'aime »
Bravo pour cet énooorme boulot !
2 « J'aime »
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 ?
A vous lire.
1 « J'aime »
Salut @eric_tonton,
Merci
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 uneX.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
masterqui 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
masterou 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.
1 « J'aime »
Salut,
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 fichiercomposer.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-devqui 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éfautcomposer.json(versionné dans spip) -
composer local truc ...fait le job mais avec le fichier personnalisé (non-versionné dans spip)
Je pense que ceci conclut cette première étape.
1 « J'aime »
Testé & approuvé (y)
Je me suis permis d’épingler ce sujet quelques temps pour suivre plus facilement, il y a des infos importantes
Faudrait garder si possible « à propos » en 1ère position mais pas vu comment faire.
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 ?
Tu parles de ce fil About the spip-dev category ? Chez moi il est bien en tête de liste.
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
Salut,
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é.
2 « J'aime »
\o/
Salut,
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 ?)
1 « J'aime »