[spip-dev] Maquette SPIPRemix, intégration de Composer dans le développement de SPIP

Dev
1

Bonsoir les amis,

Avec Marcimat et NicoD, on a mis en place une maquette (baptisée SPIPRemix) pour vous proposer une démo d’intégration de Composer dans le développement de SPIP.

Il y a un ensemble d’articles qui s’enrichiront avec le temps ici : https://spip.lerebooteux.fr/ (lire dans l’ordre : le préambule, le postulat de départ, puis le nom des choses),
Un ensemble de dépôts GIT pour faire tourner un SPIP minimaliste là : https://git-spip.lerebooteux.fr/
Et un dépôt Composer statique là : https://composer-spip.lerebooteux.fr/

L’idée derrière cet ensemble est de montrer quels sont les étapes à mettre en oeuvre pour atteindre un premier stade où Composer permettrait d’installer un SPIP, de le mettre à jour pour les utilisateurs mais aussi de développer SPIP de manière un peu plus découpée (par composants),

En gros, pour arriver à ce stade, on a fait quelques choix en essayant d’anticiper les contraintes techniques que nous rencontrerons si on fait le choix d’aller vers ce mode de développement et de distribution. Par exemple, pour des questions techniques, nous avons “migrer” le code de SPIP vers un dépôt GIT plutôt que de fournir un dépôt SVN sécurisé, alors que cela serait possible. On a choisi des noms particuliers. On n’a pas traité la question de l’historique du code et nous publions en l’état alors que la maquette ne répond pas aux problématiques de mise à jour via le web (plugin SVP et script spip_loader.php). Enfin, on n’a pas adapté tous les plugins du core, juste ceux qui étaient nécessaire à la démo.

Donc, pour ceux qui veulent tester, il est possible d’installer un SPIP depuis cette maquette avec la commande suivante, pour peu que ce soit fait sur une machine avec PHP5.3 ou plus et que composer soit installé (https://getcomposer.org/doc/00-intro.md#installation-linux-unix-osx) :

composer create-project --repository=[https://composer-spip.lerebooteux.fr/](https://composer-spip.lerebooteux.fr/) spip/spip

Récupère le code d’un SPIP “soit-disant v3.3” dans un sous-répertoire “spip” là où vous aurez lancé la commande.

composer create-project -s dev --keep-vcs --repository=[https://composer-spip.lerebooteux.fr/](https://composer-spip.lerebooteux.fr/) spip/spip spip-dev

Récupère le code d’un SPIP “” dans un sous-répertoire “spip-dev” là où vous aurez lancé la commande en conservant l’attachement à la gestion de source (GIT en l’occurence)

En espérant que le sujet vous intéresse et vous motive, nous sommes à l’écoute de vos questions.

Des bisous,

1 « J'aime »
2

Composer en utilisation, je sais un peu, mais en création de dépôt je
n'y connais que dalle, donc je te fais confiance.
Mais +1 +1 +1 pour le principe :slight_smile:

3

Super bonne nouvelle !

Dès que j’ai pris connaissance de la nouvelle, j’ai tenté l’installation de SPIP par composer. Sans accroc. (J’avais déjà composer sur ma machine. J’ai mis à jour en 1.6.5 tout de même).

Je regarde les fichiers, tout semble normal… Ou presque, il manque le répertoire “config”. L’installation par le navigateur me confirme la chose.

Soit.

Je crée ce répertoire.

L’installation se passe sans soucis. On a les plugins “minimum” qui s’installent dans plugins/spip :

  • archiviste ;

  • breves ;

  • forum ;

  • medias ;

  • sites.

Dans plugins-dist/spip, on a :

  • filtres_images ;

  • mots ;

  • organiseur.

Egalement, on trouve à la racine du site le répertoire “vendor”, classique avec composer. Il contient : composer et spip.

Et justement dans vendor/spip/ :

  • composer-installer

  • ecran_securite.

Je liste tout ça, car ça sort du schéma classique de SPIP. Surtout : vendor/spip/eran_securite/

Est-ce qu’il est bien pris automatiquement par l’installation de SPIP ? Ou est-ce que composer ne l’a pas mis (pour l’instant) dans le bon répertoire ?

En tout cas, bravo!

Je suis partant à 100% pour ce projet! :smiley:

4

+1, je vais essayer ça quand je peux

5

Super bonne nouvelle !

Dès que j'ai pris connaissance de la nouvelle, j'ai tenté l'installation
de SPIP par composer. Sans accroc. (J'avais déjà composer sur ma machine.
J'ai mis à jour en 1.6.5 tout de même).
Je regarde les fichiers, tout semble normal… Ou presque, il manque le
répertoire "config". L'installation par le navigateur me confirme la chose.

Merci du signalement.
boulette corrigée dans master ou j'expérimente l'isolation de l'écran de
sécurité en library standard

Egalement, on trouve à la racine du site le répertoire "vendor", classique

avec composer. Il contient : composer et spip.
Et justement dans vendor/spip/ :
- composer-installer

Je vais rédiger une doc spécifique sur celui-là bientôt :wink:

- ecran_securite.

Je liste tout ça, car ça sort du schéma classique de SPIP. Surtout :
vendor/spip/eran_securite/
Est-ce qu'il est bien pris automatiquement par l'installation de SPIP ? Ou
est-ce que composer ne l'a pas mis (pour l'instant) dans le bon répertoire ?

C'est bien pris en compte. Tu noteras la présence dans ./spip.php de la
ligne

require_once __DIR__ . '/vendor/autoload.php';

et la "librairie" https://git-spip.lerebooteux.fr/spip/security indique que
le fichier ecran_securite.php doit être "autoloadé" :
voir
https://git-spip.lerebooteux.fr/spip/security/src/branch/master/composer.json

Pas sur que ce soit chargé au bon moment, mais ça fait partie du chantier
de la branche de dev.

6

Hello,

Pour faire lien avec la discussion autour des branches de SPIP (débutée en mars dernier) et ce projet : https://spip.lerebooteux.fr/Scenarii-de-transition-et-de-migration-des-depots-SVN-de-SPIP

Cet article propose une liste d’opérations et de suggestions à effectuer sur le dépôt SVN actuel de SPIP. Il indique surtout quel(s) chantier(s) technique(s) mettre en œuvre préalablement à la mise en service d’un dépôt Composer dédié à SPIP. C’est plus destiné aux personnes qui gère svn://trac.rezo.net et tout ça :wink:

Amitiés,

7

Super boulot qui permet d’expérimenter, de valider, d’explorer cette idée. Je précise qu’à part du papotage, je n’ai pas fait grand chose dans l’histoire :slight_smile:

En tout cas je trouve bien d’utiliser Satis pour générer les petits zips, pour peu que l’arborescence svn ou git soit correcte.

L’intégration plus facile de composants packagés de PHP serait vraiment bienvenue, de même qu’un autoloader et plein de jolies choses.

L’épine qui me semble rester est la gestion d’un processus d’installation graphique (encore que, il suffit de générer un zip complet comme avant ?) et de l’UI de recherche et téléchargement de plugins, si on doit la conserver…

En tout cas grand merci à vous deux de vous plonger dedans :slight_smile:

MM.

8

Il serait en effet assez facile d'étendre satis pour générer une archive
"classi(c|que)" pour un spip_loader.php/un plugin svp "composer
compatibles".
Le plus dur resterait à coder le script et le plugin pour devenir
compatible avec un dépôt Composer où trouver SPIP.

Perso, je suis pas chaud avec l'installation par le web et une GUI. Mais
bon, ça compte pour un peu de monde, j'aiderai ceux qui souhaitent s'y
mettre.

Autres épines : séparer la configuration des plugins des éléments
d'installation*, la mutualisation de sites, l'arbo de base (avec spip.php à
la racine du projet, c'est pas top), et la façon d'initialiser spip lors
d'une requête (inc_version.php, inc/utils.php, etc.), sujets qui me bottent
plus :wink:

*éviter de faire d'un fichier composer.json un fourre-tout et lui laisser
pour seul rôle ce pour quoi il est fait, à savoir les dépendances,
l'autoload, l'installation)

9

Hello,

Bonsoir les amis,

Avec Marcimat et NicoD, on a mis en place une maquette (baptisée SPIPRemix) pour vous proposer une démo d’intégration de Composer dans le développement de SPIP.

Quand on parle de Git je fuis en général mais là comme c’est les vacances j’ai quand même essayé ;-).

En lançant la commande proposée j’ai bien obtenu un spip mais j’ai eu quelques messages d’erreur surement dus à mon environnement mais bon je vous les donne :

Cannot create cache directory /Users/eric/.composer/cache/repo/https—composer-spip.lerebooteux.fr/, or directory is not writable. Proceeding without cache
Installing spip/spip (dev-master c15f12534b217dbd65d4a6c4218a69223b062eae)
Cannot create cache directory /Users/eric/.composer/cache/files/, or directory is not writable. Proceeding without cache

  • Installing spip/spip (dev-master master): Cloning master
    Created project in SPIPDEV
    Cannot create cache directory /Users/eric/.composer/cache/repo/https—composer-spip.lerebooteux.fr/, or directory is not writable. Proceeding without cache
    Cannot create cache directory /Users/eric/.composer/cache/repo/https—packagist.org/, or directory is not writable. Proceeding without cache
    Cannot create cache directory /Users/eric/.composer/cache/files/, or directory is not writable. Proceeding without cache

Je suis sous osx et j’ai lancé la commande à partir de eric/sites/ pour obtenir un spip dans eric/sites/SPIPDEV/.

Ce que je ne comprends pas aussi c’est pourquoi chercher à créer des répertoires dans eric/ alors que je m’attendais plus à eric/sites/ ?

10

[...]

En lançant la commande proposée j'ai bien obtenu un spip mais j'ai eu quelques messages d'erreur surement dus à mon environnement mais bon je vous les donne :

Cannot create cache directory /Users/eric/.composer/cache/repo/https---composer-spip.lerebooteux.fr/ <http://https---composer-spip.lerebooteux.fr/&gt;, or directory is not writable. Proceeding without cache

[...]

Je suis sous osx et j'ai lancé la commande à partir de eric/sites/ pour obtenir un spip dans eric/sites/SPIPDEV/.
Ce que je ne comprends pas aussi c'est pourquoi chercher à créer des répertoires dans eric/ alors que je m'attendais plus à eric/sites/ ?

[...]

En fait, Composer partage un cache des librairies (dans ~/.composer), ce qui fait que si tu lances des 'composer install' ou autres choses, il va commencer par regarder si le contenu souhaité est en cache, auquel cas, ça ira plus vite pour le copier dans ton projet, plutôt que de le récupérer sur le web.

Maintenant, qu’il n’est pas pu créer ce répertoire chez toi, je ne sais point pourquoi.

MM.

11

On peut continuer la démo avec un petit truc marrant :

après cette installation, vous pouvez ajouter un plugin :


composer require jamesrezo/spip-rose

puis activer le plugin dans l’interface d’admin

ce plugin fort utile est développé sur github https://github.com/JamesRezo/spip-rose

et mis à disposition ici https://packagist.org/packages/jamesrezo/spip-rose

:wink:

12

et maintenant, un plugin encore plus nécessaire :


composer require jamesrezo/cms-vert

ce plugin est développé sur la zone : https://zone.spip.org/trac/spip-zone/browser/composer/cms-vert

et mis à disposition (sans archivelist.txt :p) ici https://composer-spip.lerebooteux.fr/#jamesrezo/cms-vert

A+

13

Salut les gens,

Quelques infos sur la mise en place du dépôt composer de SPIPRemix :

https://spip.lerebooteux.fr/Mise-en-place-du-depot-Composer

Bonne lecture ! :slight_smile:

Amitiés,

14

Hello,

15

Un fichier composer.json n’a pas vocation à être multilingue, ni, dans l’absolu, à servir de fichier de configuration ou de collecte de données. Un autre fichier sera donc nécessaire, ne serait-ce que pour le multilinguisme.

Maintenant, mon avis perso, qui n’est qu’un avis, c’est effectivement contre-intuitif de concevoir qu’il serait nécessaire de fournir 2 fichiers pour un composant et pour autant, c’est ce que je préfèrerais voir apparaître : un fichier composer.json pour l’installation et la gestion de dépendance, le dépôt composer pour le versionning à travers les branches et les tags de la gestion de source associée au composant et un autre fichier de configuration/information (pour les pipelines, les menus, certaines chaines multi et ne gérant pas versions et niveaux de stabilité), si possible en JSON, ou autre format comme yaml par exemple, et plutôt pas en XML. Mais c’est qu’un avis perso.

En gros, on pourrait considérer que la partie composer n’a pas à être “surchargée” mais que la partie configuration/paramétrage pourrait l’être.

Rien n’est décidé ni gravé dans le marbre, la discussion reste ouverte. SPIPRemix n’a pas vocation, selon moi, à trancher cette question.

16

Bonjour à tous :blush:

En lisant un peu https://spip.lerebooteux.fr/Mise-en-place-du-depot-Composer Je me suis rendu compte d’un truc qui m’interroge ! :smiley:

Tu parles de la possibilité de faire l’arrêt de archivlist.txt car devenant inutile !

Par contre, je vois trois problèmes à l’arrêt (même si par simplicité, le mieux est peut-être d’en faire l’arrêt), c’est que sur la zone, Il y a des plugs qui :

  • N’ont pas de zip en route car l’auteur estime que c’est trop tôt !
  • Des plugs qui contiennent plusieurs branches qui sont, compatible avec par exemple spip 3.0, mais dont il n’y a qu’une version dont le zip est route.
  • Il y a aussi de très vieux plug sur la zone qui n’ont pas de zip, mais qui n’en n’auront jamais car beaucoup trop vieux…

Faire des zip des très vieux plugs posera problèmes, car à une époque, les bornes de compatibilité max étaient absente, donc, nous risquons de voir apparaitre des plugs dit compatible, alors que cela ne sera pas du tout le cas… :frowning:

Franck

17

Yep Franck,
ce n'est pas parce qu'il n'y aura plus archivelist, que ce ne sera plus
manuel. À priori les paquets composer sont générés à partir d'une
description en JSON de chaque élément qui veut entrer dans le dépôt.
Donc si un plugin n'a pas d'infos en JSON, bah il ne sera pas dans le
dépôt. C'est toujours des choix manuels, de ce que j'ai compris.

18

Ok ok, je pensais que cela devenait automatique
Merci de l'info RastaPopoulos :blush:

-----Message d'origine-----

19

Salut,

Aujourd’hui, j’ai fait un petit test pour reconstituer l’historique de l’écran de sécurité, développé sur la zone depuis 12 ans, dans un dépôt git.

La difficulté, c’est que le dev de l’écran à été déplacé à plusieurs moment de son histoire et qu’il n’y a pas de répertoires trunk/branches/tags

après examen des logs, j’ai produit un petit shell bash pour faire le boulot :

#!/bin/bash

rm -f _securite_trunk_.dump

svnrdump dump -r 0:27939 svn://[zone.spip.org/spip-zone/_securite_](http://zone.spip.org/spip-zone/_securite_) | svndumpfilter include --drop-all-empty-revs --renumber-revs --skip-missing-merge-sources --preserve-revprops /_securite_ > _securite_.dump
LANG=C sed 's/_securite_/trunk/' _securite_.dump > _securite_trunk_.dump

rm -Rf security securitywc
svnadmin create --compatible-version 1.9 security
svnadmin load --normalize-props -F _securite_trunk_.dump security

# svnrdump dump -r 27940:28912 --incremental svn://[zone.spip.org/spip-zone/_core_/_securite_](http://zone.spip.org/spip-zone/_core_/_securite_) | svndumpfilter include --drop-all-empty-revs --renumber-revs --skip-missing-merge-sources --preserve-revprops /_core_/_securite_ > _securite_.dump
# LANG=C sed 's/_core_\/_securite_/trunk/' _securite_.dump > _securite_trunk_.dump

# Pas de changements du code

# svnrdump dump -r 28913:28916 --incremental svn://[zone.spip.org/spip-zone/_core_/securite](http://zone.spip.org/spip-zone/_core_/securite) | svndumpfilter include --drop-all-empty-revs --renumber-revs --skip-missing-merge-sources --preserve-revprops /_core_/securite > _securite_.dump
# LANG=C sed 's/_core_\/securite/trunk/' _securite_.dump > _securite_trunk_.dump

# Pas de changements du code

svnrdump dump -r 28917:HEAD --incremental svn://[zone.spip.org/spip-zone/_core_/securite](http://zone.spip.org/spip-zone/_core_/securite) | svndumpfilter include --drop-all-empty-revs --renumber-revs --skip-missing-merge-sources --preserve-revprops /_core_/securite > _securite_.dump
LANG=C sed 's/_core_\/securite/trunk/' _securite_.dump > _securite_trunk_.dump
svnadmin load --normalize-props -F _securite_trunk_.dump security

git svn clone -s file:///Users/klike/Sites/SpipRemix/[zone.spip.org/security](http://zone.spip.org/security) securitywc

cd securittywc

Plus qu’à pousser dans un dépôt git public sur Internet…

Résultat ici : https://git-spip.lerebooteux.fr/JamesRezo/ecran_securite

Puis poursuivre en fusionnant avec l’autre test sur l’écran qui est ici : https://git-spip.lerebooteux.fr/spip/security

L’idée, c’est de trouver un moyen à peu près similaire pour les plugins “core” de les reconstituer en suivant le standard layout et semver (des branches et des tags qui correspondent aux versions des plugins eux-mêmes (trouvables dans les paquet.xml) et non de SPIP, que ça reste dans du SVN ou que ça passe dans du GIT, peu importe. Cela permettra de référencer le code source de chaque plugin (ici, ceux du core) dans un dépôt composer avec leurs propres versions et les faire correspondre à celles actuellement associées via le procédé “svn:externals” dans les versions maintenues du SPIP historique…

Voilà, voilà :slight_smile:

20

Wow ! Excellent !