Faire une distribution alternative et conclusion

, par James

TL ; DR

composer create-project geodiv/geodiv

Oui, mais encore ?

PHP>7.1 (spip/cms 3.1.*)

Le squelette Géodiversité est basé sur SPIP 3.1 qui n’est, au jour où cet article est publié, compatible que jusqu’à PHP 7.1 [1].

Si vous utilisez une version PHP plus récente :

composer create-project --ignore-platform-reqs geodiv/geodiv

Librairies externes

SVP n’a pas été traité dans le cadre de cette maquette. Géodiversité a besoin de 2 librairies à installer à la main.

Pour terminer pleinement l’installation et permettre d’activer tous les plugins nécessaires, il faut donc faire ceci à la racine du projet :

Et hop :)

Bruno B., 15 juin 2018, avant 14h.

De plus, le chantier de l’autoloading étant aussi hors périmètre, le composant newerton/jquery-mousewheel ne pouvait, par exemple, être intégré en tant que dépendance.

packagist

Vous aurez remarqué que, contrairement à Les versions "Classic" 3.0, 3.1 et 3.2, il est possible d’installer le projet geodiv/geodiv sans avoir recours à l’option --repository=https://.... C’est parce que le projet est référencé sur Packagist.Org.

github

Géodiversité est, depuis toujours, développé sur github. Pour poursuivre l’exploration et l’étendue de composer, nous avons souhaité montrer à travers cette dernière démonstration que les dépôts de code pouvaient être divers. Nous avons donc créée l’organisation spipremix temporairement et nous y avons migré les plugins "non-core" requis pour geodiv en suivant un mode opératoire similaire, quoique simplifié, à celui des plugins "core". En particulier, seules les branches compatible avec SPIP3.1 minimum ont été converties pour l’expérience.

Méthodologie

Réceptacle de l’application

Le clonage du projet spip/spip, puis ses adaptations permettent de spécifier des plugins/extensions complémentaires. On constatera qu’ici, les adaptations consistent en la modification des fichiers composer.*. L’arborescence des fichiers reste celle d’un site SPIP classique. Il est parfaitement possible d’imaginer qu’une distribution alternative pourrait contenir d’autres répertoires, pour des besoins non couverts par le SPIP que l’on connait aujourd’hui. Il serait aussi possible, mais pas très recommandé, de livrer un réceptacle avec un répertoire ./squelettes complet...

Il est à noter qu’il na pas été possible de procéder au remplacement du squelette par défaut [2]. Ceci est, entre autres, lié au fait que le fichier paquet.xml du plugin installé dans le répertoire ./squelettes-dist n’est pas pris en compte par le gestionnaire de plugins de SPIP. C’est un chantier pour SPIP lui-même et ses contributions.

Dans l’idéal, on aurait du avoir :

"geodiv/squelettes" requierant "spipremix/zcore", requierant lui-même "spip/dist".

Les squelettes proprement dits

Pour les squelettes, c’est un filtrage par git du dépôt initial, un peu comme fait précédement pour les répertoires ./prive et ./ecrire [3].

Remarques sur la conversion de plugin

Les branches

Le sous-répertoire "branches" du standard layout de subversion, ou les branches git, sont interprétées par composer de 2 manières :

  • une branche de fonctionnalité (feature branch) si le libellé de la branche ne contient pas de terme de comparaison pour le résolveur de dépendance. En gros, un mot pour décrire une fonctionnalité en cours de développement, ex : « nuage_sans_bonux ».
  • une branche de maintenance d’une version si le libellé de la branche est un terme de comparaison pour le résolveur de dépendances. En gros, une valeur numérique tel que 1.3, 2.0, 4, ...

La plupart des branches trouvées sur la Zone correspondent à des branches de maintenance. Par exemple nuage_v2, n’est pas une version correcte et devrait s’appeler 2.0. Une branche v0_3 devrait plutôt s’appeler 0.3, etc.

version et stabilité

Pour passer à une gestion un peu plus rigoureuse, et compatible avec composer, on peut déjà se fixer quelques guides :

  • L’état « expérimental », peu utilisé, devrait être remplacé par des branches 0.x et des tags 0.x.y,
  • Les versions 0.x et 0.x.y avec un état stable devrait passer en version 1.0 et avoir au minimum un tag 1.0.0,
  • L’état « test » devrait être remplacé par des tags en x.y.z-alpha<n>, x.y.z-beta<n> et/ou x.y.z-RC<n>,
  • L’état stable devrait être remplacé par des tags en x.y.z.

Ceci permettrait d’éviter les commits intempestifs de fichiers paquet.xml pour des "up de z" ou "up de y" hasardeux.

Pour incrémenter les numéros de version, posez-vous la question, posez-là aux contributeurs de vos plugins, faites des tags quand ça se justifie, pas nécessairement à chaque changement/commit, et faites des "branches" de maintenance dans git ou svn quand cela à un sens. Enfin, supprimer une branche de maintenance quand une version n’est plus maintenue peut être considéré comme un signe de bonne santé : la base de code est vivante, le HEAD du dépôt global ne contient que du code exploitable, etc.

Il est bon de rappeler que ce n’est pas utile de suivre les versions de SPIP pour versionner les plugins, chaque plugin pouvant avoir son propre cycle de vie. La compatibilité avec SPIP peut se gérer en spécifiant une version précise dans le fichier composer d’un réceptacle et le chantier spip/sdk (plus bas) pourra garantir la compatibilité (et remplacer l’attribut dans paquet.xml) avec spip.

Les années de copyright dans les fichiers

J’ai pu observer que certains plugins ne sont mis à jour que lors du passage d’une année. Cela donne l’illusion que le plugin est toujours maintenu et c’est une mauvaise chose. De plus, il est plus pratique, pour cette information, de la centraliser dans un fichier de licence, à la racine du plugin, plutôt que dans chacun des fichiers qui le compose. Dernière chose, la bannière utilisée dans les fichiers SPIP ne concernent que SPIP, pas vos plugins...

Le nom

Choisissez un « vendor » qui corresponde à l’équipe qui assurera la maintenance et la distribution du plugin. Si vous êtes seul à développer et à maintenir un plugin, utilisez votre nom ou pseudonyme, par exemple jamesrezo/spip-rose. Si clea correspond à une organisation sur un serveur git, c’est mieux. Ne copiez pas bêtement le vendor du voisin, les vendor "spip" et "spipremix" sont déjà pris. Il est possible que "spip-zone" soit le bon vendor si le plugin est développé sur la Zone et que la communauté prend en charge sa maintenance. Si https://git.spip.net/ entre en service un jour, il faudrait qu’il soit possible de créer des dépôts, voire des organisations qui correspondent aux vendors des plugins et non à l’ancienne organisation technique du serveur subversion...

À propos de l’aspect typographique, utilisez des lettres minuscules, sans accents, les tirets (-) et underscore (_) peuvent servir, mais c’est moins joli. Cela vaut aussi pour les organisations git et les vendors.

spip/sdk

Il serait profitable de mettre à disposition une librairie qui défini l’api de base de spip : fournir include_spip(), spip_log(), charger_fonction() et peut-être quelques autres fonctions et constantes de base. Grosso modo les fonctions décrites ici ainsi qu’un certain nombre de constantes liéés au fichier ecrire/inc_version.php.

Elle serait très utile pour définir la compatibilité avec le composant spip/ecrire principalement, pour faire des Tests Unitaires, avec PHPUnit, par exemple, ...

Ainsi les contraintes ci-dessous seraient équivalentes

Autres chantiers

  • Bien vérifier les contraintes de plates-formes (versions et extension php, ...)
  • Homogénéiser l’arboresence stand-alone et le mode mutualisé,
  • Sécuriser l’hébergement en proposant une arborescence qui permet de réduire l’accès aux fichiers (./public pour le serveur web, ./var pour les accès en écriture, par exemple),
  • SVP, spip_loader, l’installation par le web en général (et les risques liés à la sécurité)
  • Un jeu de squelettes "dist-mini", sans dépendances à spip/breves, forum, spip/sites et spip/medias.
  • Mettre en oeuvre un système "moderne" de migrations et de seeds, avec Phinx par exemple, pour permettre la mise en place des schémas de base de données en ligne de commande, par exemple.
  • Mettre en place un autoloading PSR-4, puis améliorer le mécanisme de "bootstrapping" de SPIP.

Mais aussi et peut-être en priorité, les fichiers de langues en partant de ce qu’on a :

Un type de composant "spip-lang" a été pré-réservé dans le plugin composer "spip/composer-installer" pour le cas où les fichiers de langues devraient être gérés dans des composants indépendants vis-à-vis de leurs plugins.

Conclusion

Moyennant une reconstruction propre des dépôts git et de procéder à la construction des dépôts git des plugins core qui restent à faire (https://spip.lerebooteux.fr/Les-plugins-Core#nb2-7), le système proposé fonctionne et il est opérationnel. Sans changer une ligne de code dans SPIP et ses plugins proprement dit.

Sans perdre les usages actuels (svp, spip_loader.php, files.spip.net, plugins.spip.net), en produisant les zips classiques de SPIP avec composer, on peut commencer à se débarrasser de smart_paquets.

Une alternative est possible et peut servir de point de départ à de nouveaux chantiers pour SPIP3.3 et plus : une voie pour faire évoluer SPIP est dessinée.

Cette dernière étape m’a permis d’identifier d’autres points (en plus de ceux évoqués au cours des articles précédents ou sur spip-dev) pouvant être améliorés plus ou moins facilement :

  • maintien et mise à jour de l’écran de sécurité (via l’autoloader de composer),
  • encapsulation de lib anciennes comme pclzip, phpmailer et yaml par exemple, pouvant être remplacées ou intégrées en tant que librairie standard,
  • transformation de certaines fonctionnalités aujourd’hui exclusivement spipiennes en librairies standard,
  • cas du répertoires ./lib.

La communauté SPIP peut désormais faire des choix, adopter une stratégie ...

  • Dernières versions
  • 4.2.9 : 8 février 2024
  • 4.1.15 : 12 janvier 2024