Les plugins "Core"

L’intégration de Composer dans la gestion des plugins de la distribution "Classic" de SPIP est le problème technique le plus complexe à résoudre. La question de leur installation a été réglé grâce à L’installeur Composer pour SPIP. Toutefois, pour qu’un dépôt Composer puisse être mis à jour à chaque changement et que l’historique du code de ces plugins soit préservé en cas de migration vers des dépôts GIT [1] ainsi que de régler, par étape, la contrainte technique que pose l’utilisation du mécanisme des « externals » de subversion, il est nécessaire de réorganiser les branches de développement et de maintenance de ces plugins. Voici une solution qui propose une méthode à la fois systématique et progressive pour ce faire.

Historique de la gestion du code source des plugins du core

À une époque où Composer n’existe pas encore et où la seule solution technique assez répandue est PEAR, et que celle-ci ne peut satisfaire les besoins des installations SPIP, c’est vers le logiciel de gestion de versions subversion que l’équipe se porte pour l’externalisation des fonctionnalités de SPIP. Les étapes sont simples et de bon sens :

• On supprime le code d’une fonctionnalité dans le dépôt subversion de SPIP.
• On crée un plugin sur la Zone dans lequel on rassemble le code de cette fonctionnalité.
• On référence l’adresse du plugin via le mécanisme natif de subversion des « externals ».

C’est donc en juin 2010 que les travaux de découpage du noyau SPIP débutent, en commençant par le déplacement du code des squelettes par défaut sur la zone :

• Dépôt initial de l’extension "dist_2007"
• Passage des squelettes de la dist en extension puis
• external du dossier extensions sur core/plugins de la zone

• svn pg svn:externals -r 15739 svn://trac.rezo.net/spip/spip
  extensions svn://zone.spip.org/spip-zone/_core_/plugins

• Extrait du commentaire :

  L’autre solution serait de faire un répertoire extensions, avec des externals sur chaque extension séparément.
  Ça aurait l’avantage de ne pouvoir inclure que les plugins vraiment mûrs

Le jeu de squelettes était déjà isolé dans un répertoire bien à lui. Il n’en était pas de même pour les fonctionnalités qui furent externalisés par la suite mais la solution technique, qui évoluera dans le sens de la remarque de l’ami davux, restera la même [2].

Le modèle s’est donc stabilisé au cours du développement de SPIP3.0 et, pour chaque <plugin> on propose désormais les adresses suivantes :

svn://zone.spip.org/spip-zone/_core_/plugins/<plugin>/paquet.xml
svn://zone.spip.org/spip-zone/_core_/branches/spip-3.0/plugins/<plugin>/paquet.xml
svn://zone.spip.org/spip-zone/_core_/branches/spip-3.1/plugins/<plugin>/paquet.xml
svn://zone.spip.org/spip-zone/_core_/branches/spip-3.2/plugins/<plugin>/paquet.xml

Avantages

• Il devient donc aisé d’assembler le code de SPIP depuis ses différents dépôts. Avec une seule commande (svn co svn://...), on peut récupérer sur sa machine de développement ou sur le serveur hôte de l’application l’ensemble du code pour la version de SPIP choisie. Accessoirement, on peut le faire pour produire une archive ZIP qui sera mise à disposition pour un téléchargement ultérieur.
• Avec une seule commande (svn up), on peut aussi mettre à jour le code de SPIP. On peut aussi télécharger le nouveau ZIP qui aura été produit.

Inconvénients

• On ne pourra toutefois pas mettre à jour d’autres plugins avec cette unique commande, ni se passer d’une fonctionnalité non souhaitée.
• D’autres part, bien qu’ayant une granularité plus fine dans le référencement des adresses « svn », la tradition de gérer les branches en fonction de la version de SPIP et non du plugin lui-même est conservée. Ainsi, les versions des plugins du core n’ont que peu d’intérêt.
• On ne peut, de manière simple, mettre à jour un plugin du core qu’en changeant de version de SPIP.
• Enfin, parce que le mécanisme de référencement des plugins est lié à l’outil subversion, il devient difficile de le remplacer par, ou de le faire cohabiter avec un autre logiciel de gestion de versions.

Cible

Pour passer à l’utilisation de Composer, il apparaît nécessaire de changer le mode de gestion des plugins.

Pour chaque plugin, on doit transformer l’organisation des répertoires comme ci-dessous :

svn://zone.spip.org/spip-zone/_composer_/<plugin>/trunk/paquet.xml
svn://zone.spip.org/spip-zone/_composer_/<plugin>/branches/<branche>/paquet.xml

Pour déterminer une <branche>, il est proposé de conserver les numéros de version MAJEUR et MINEUR défini dans le fichier paquet.xml

Le cas échéant [3] :

svn://zone.spip.org/spip-zone/_composer_/<plugin>/tags/<tag>/paquet.xml

Où <tag> devra correspondre à la valeur de la version saisie dans le fichier paquet.xml.

• Il sera possible de régler la propriété svn:externals dans les branches de SPIP sur ces nouveaux emplacements [4]
• Le script ci-dessous devrait aider à gérer le changement des adresses dans le dépôt subversion de SPIP : svn pg svn:externals svn://trac.rezo.net/spip/spip > externals_trunk.txt sed 's/_core_\/plugins\/jquery_ui/_composer_\/jquery_ui\/trunk/' externals_trunk.txt > new_externals_trunk.txt svn propedit svn:externals -F new_externals_trunk.txt -m "Déménagement plugin-dist jquery_ui" svn://trac.rezo.net/spip/spip svn pg svn:externals svn://trac.rezo.net/spip/branches/spip-3.0 > externals_3.0.txt sed 's/_core_\/plugins\/jquery_ui/_composer_\/jquery_ui\/3.0/' externals_3.0.txt > new_externals_3.0.txt svn propedit svn:externals -F new_externals_3.0.txt -m "Déménagement plugin-dist jquery_ui" svn://trac.rezo.net/spip/spip svn pg svn:externals svn://trac.rezo.net/spip/branches/spip-3.1 > externals_3.1.txt sed 's/_core_\/plugins\/jquery_ui/_composer_\/jquery_ui\/3.1/' externals_3.1.txt > new_externals_3.1.txt svn propedit svn:externals -F new_externals_3.1.txt -m "Déménagement plugin-dist jquery_ui" svn://trac.rezo.net/spip/spip svn pg svn:externals svn://trac.rezo.net/spip/branches/spip-3.2 > externals_3.2.txt sed 's/_core_\/plugins\/jquery_ui/_composer_\/jquery_ui\/3.2/' externals_3.2.txt > new_externals_3.2.txt svn propedit svn:externals -F new_externals_3.2.txt -m "Déménagement plugin-dist jquery_ui" svn://trac.rezo.net/spip/spip

  .

• Il sera beaucoup plus facile d’opérer à la migration du code vers des dépôts « git ».

Versions des plugins définies dans les fichiers paquet.xml par branche de maintenance SPIP

Plugins mandataires

echo "3.3.x-dev" && svn cat svn://zone.spip.org/spip-zone/_core_/plugins/<plugin>/paquet.xml | grep version
echo "3.2" && svn cat svn://zone.spip.org/spip-zone/_core_/branches/spip-3.2/plugins/<plugin>/paquet.xml | grep version
echo "3.1" && svn cat svn://zone.spip.org/spip-zone/_core_/branches/spip-3.1/plugins/<plugin>/paquet.xml | grep version
echo "3.0" && svn cat svn://zone.spip.org/spip-zone/_core_/branches/spip-3.0/plugins/<plugin>/paquet.xml | grep version

Autres Plugins

On en déduit les branches de maintenance des plugins, par exemple 1.12, 1.11 et 1.8 pour jquery_ui.

Le script ci-dessous permet de récupérer l’arborescence actuel d’un plugin du core et de créer sa nouvelle organisation en observant à le standard layout et semver :

On peut faire des svn mv ... au lieu des svn cp ..., ou supprimer les anciens emplacements :

Plugin suivant :

Éventuellement, la migration vers GIT :

Ajouter un fichier composer.json :

et un fichier .gitignore pour chaque branche :

Supprimer le plugin sur le dépôt subversion de la zone : svn rm ${ZONE_SVN_ROOT}/_composer_/jquery_ui.

Déréférencer le plugin dans les externals :

Et ainsi de suite...