Définition actuelle d’une extension

Une extension est actuellement un plugin de SPIP placé dans un dossier spécifique séparé à la racine, nommé « extensions/ ». Ce plugin est activé dès l’installation de SPIP et ne pourra jamais être ni désinstallé ni désactivé.

Définition actuelle d’une distribution

Une distribution est une fusion du noyau de SPIP, livré avec une collection d’extensions déjà placées dans le dossier idoine.

Actuellement la distribution officielle, nommée tout simplement « SPIP », est construite avec le paramètre svn:externals qui va télécharger les extensions choisies sur la Zone.

Problèmes

Actuellement il y a un mélange entre deux fonctionnalités :

• Activer un plugin par défaut lors de l’installation du SPIP
• Rendre un plugin intouchable

Il n’y a aucun moyen de construire plusieurs distributions différentes, notamment parce que le mécanisme pour construire la distribution officielle dépend du gestionnaire de version (ici SVN).

Que veut-on ?

Définissons maintenant le cahier des charges de ce que devrait être une distribution en essayant de n’oublier aucune contrainte.

• Pouvoir définir explicitement le contenu d’une distribution
• Séparer les fonctionnalités « plugins par défaut » et « plugins intouchables »
• Ne pas dépendre de SVN (ou autre) dans la méthode de déclaration
• Permettre de générer un ZIP à partir de la description d’une distribution
• Permettre la mise à jour d’une distribution aussi par SVN

Proposition générale : un fichier déclaratif

La solution que je propose est de supprimer définitivement le dossier extension/ et d’utiliser un nouveau fichier dédié qui définira le contenu de la distribution.

Format et emplacement du fichier

Deux formats viennent à l’esprit : XML et YAML.

Actuellement, seul le XML est lisible directement par le noyau de SPIP. Si l’on veut utiliser un format YAML, alors il faudra intégrer une librairie au moins minimale (qui suffit pour l’utilisation de type « fichier de conf ») à l’intérieur du noyau, et non en plugin. En effet, le core doit savoir mettre en place la distribution sans plugins externes... : logique !

En attendant de statuer sur ce point, nous utiliseront le format XML dans les exemples.

L’emplacement proposé serait config/distribution.xml.

Les deux utilisations

Le même fichier de déclaration d’une distribution sera utilisé pour deux grands types de besoins.

En interne :

• informer sur la distribution (son nom, son URL de doc), notamment pour le pied de page de l’espace privé
• activer les plugins déclarés dès l’installation
• interdire de désactiver les plugins qu’on a décidé intouchables

En externe :

• générer un paquet ZIP d’une distribution, uniquement en donnant le même fichier XML à manger à un script

Exemple de fichier

<distribution>
	<!-- Les informations sur cette distribution précise -->
	<nom>SPIP-Collectivité</nom>
	<version>0.9</version>
	<!-- URL du projet, comme pour la doc d'un plugin -->
	<url>http://www.mon-url.info/</url>
	<!-- URL du fichier de description, pour permettre des mises à jour automatique -->
	<url_distribution>http://www.mon-url.info/distribution.xml</url_distribution>
	
	<!-- Les plugins non-désactivables -->
	<necessite id="SPIP" version="[3.0.0;]" />
	<necessite id="compresseur" version="[x.x.x;]" />
	<necessite id="memoization" version="[x.x.x;]" />
	<necessite id="yaml" version="[x.x.x;]" />
	<necessite id="saisies" version="[x.x.x;]" />
	<necessite id="verifier" version="[x.x.x;]" />
	<necessite id="textwheel" version="[x.x.x;]" />
	<necessite id="facteur" version="[x.x.x;]" />
	<necessite id="menus" version="[x.x.x;]" />
	<necessite id="pages" version="[x.x.x;]" />
	<necessite id="zcore" version="[x.x.x;]" />
	<necessite id="zcollectivite" version="[x.x.x;]" />
	
	<!-- Les plugins activés par défaut à l'installation, mais désactivables ensuite -->
	<utilise id="formidable" version="[x.x.x;]" />
	<utilise id="organigramme" version="[x.x.x;]" />
	<utilise id="comarquage" version="[x.x.x;]" />
</distribution>

Comportement en interne

À l’installation :

• SPIP installe le noyau comme habituellement
• S’il n’y a pas de fichier config/distribution.xml c’est fini
• Sinon SPIP scanne le fichier et active les plugins qui sont à la fois déclarés dedans, et trouvés dans le dossier des plugins/ (ou dans des sous-dossiers).

Dans l’admin des plugins :

• SPIP scanne le fichier de distribution
• Les plugins qui sont en <necessite> dedans sont affichés séparément et ne peuvent pas être désactivés

On voit que le préalable à cela est que SPIP doit garder dans son noyau les fonctions de recherche des plugins dans son (ou ses ! pour une mutu) dossier plugins/, et d’activation.

Pour ne pas faire de redondance, il faudrait qu’elles puissent être utilisées ensuite telles quelles par STEP, qui ajoutera des fonctions de chargement depuis l’extérieur (en plongeant dans la base SVP). Mais l’activation doit bien rester dans le core, puisque celui-ci doit évidemment être capable de fonctionner seul, et notamment d’activer STEP... sans STEP !

Utilisation externe : générer des paquets

Grâce aux informations contenues dans la description, il sera possible de générer des paquets complets de distributions de SPIP.

Pour cela, un script prenant en paramètre un fichier de description devra :

• créer un dossier temporaire
• scanner la liste des <necessite> et <utilise>
• récupérer les paquets de tous ces plugins et les dézipper dans un sous-dossier plugins/
• récupérer la version du noyau indiqué
• déplacer le fichier de description dans le dossier config/ et le renommer en distribution.xml
• Ziper tout cet ensemble et nommer le ZIP, soit via un paramètre explicite, soit s’il n’est pas renseigné selon le nom du fichier XML fourni + la version de la distribution. Par exemple spip-collectivite.xml => spip-collectivite-0.9.zip.

Réflexion sur les mises à jour des extensions

Il y a un point qui n’est pas éclairci, c’est celui des mises à jour des plugins non-désactivables.

Doit-on permettre un changement de version ? Prenons l’exemple déjà arrivé du Porte-Plume : s’il est amélioré et que SVP détecte une montée de version, est-ce que STEP, ou SPIP-Core, doit autoriser la mise à jour si ce plugin fait partie des « extensions » ?

Le plus explicite est peut-être de suivre les directives indiquées par l’attribut version="[x.x.x;] de la déclaration :

• Si on indique uniquement une version minimum, alors SPIP autorise la montée de version.
• Si on indique une version maximum, il est interdit de mettre à jour, à moins de le faire à la main dans les fichiers du serveur, mais dans ce cas le plugin n’est plus reconnu comme faisant partie de la liste des extensions, et n’est donc plus forcément activé.