Re: [SPIPremix] Une distribution SPIP alternative

Le 14/06/2018 à 22:29, James a écrit :

> Pour tester son installation, tapez : composer create-project 
> geodiv/geodiv ;)

Hello :)

Si je comprends bien, le create-project met à la racine les fichiers du 
paquet spip/spip ou geodiv/geodiv.

On est d’accord que du coup, un composer update ne mettra pas à jour ces 
fichiers racine ? En général on n’y touche effectivement pas, mais ça 
sera à préciser quand même probablement.

J’aimerais bien faire un petit point pour savoir ce qu’il reste à faire, 
à réfléchir, quels sont les décisions à prendre, etc.


Sur Composer
------------

Déjà, pour rappeler mon avis, je pense qu’il faut déléguer dans SPIP le 
système de gestion de dépendances et d’installation (ce que fait 
Composer), pour différentes raisons (entre autres pour être un peu plus 
en phase avec la communauté PHP) ; et plus tard réutiliser des 
librairies existantes pour certains de nos besoins.

Comme SpipRemix le montre, cela soulève tout de même certaines 
problématiques d’organisation (des dépots), et modifie les usages, sans 
être bloquant non plus.


Organisation des dépots
-----------------------

Pour que le Packagist (idéalement) ou Satis (avec un peu d’huile de 
coude) puisse fournir les versions correctes des paquets (requis dans 
composer.json), il faut des dépots Git ou Svn carrés.
Carrés sur l’organisation trunk/branche/tags et sur la numérotation des 
versions Semver.

Ça veut dire qu’il faut réorganiser un certain nombre de choses sur le 
SVN (ou Git), notamment les plugins-dist sur la Zone. Ce n’est pas 
infaisable comme l’a montré James. Par contre il faudra qu’on soit 
attentifs à fournir correctement des tags/x.y.z des versions que l’on 
sort sur chaque paquet, si je comprends bien.


Cas des dépots du core
----------------------

Le dépot du core sera aussi découpé en 3 paquets (spip, ecrire, prive).
Ce découpage, surtout ecrire/privé n’est pas très pratique pour commiter 
des modifications (les 2 vont quand même un peu de pair). Est-ce que 
c’est quelque chose de temporaire ? Est-ce qu’ils peuvent être des 
subtree d’un dépot Git plus gros ? (c’est peut être pas une bonne idée 
non plus). Est-ce qu’ils ont des versions indépendantes les uns des autres ?


Zips des plugins (smart paquets)
--------------------------------

Dans cette nouvelle organisation, l’outil smart_paquets (qui crée les 
zips des plugins actuels) et le fichier archivelist.txt deviennent 
caduques.

Cependant cela crée aussi deux problèmes :

1) SVP (avec composer)
----------------------

SVP ne saurait plus installer de nouveaux plugins de lui-même (juste 
gérer leur activation / désactivation).

Ceci dit une solution toute Composer voudrait qu’on "require" sur le 
site seulement les plugins nécessaires à celui-ci, et ces plugins 
pourraient être actifs par défaut dans SPIP. Ou on garde le principe de 
pouvoir activer / installer / désactiver / désinstaller un plugin depuis 
la page des plugins (mais plus le téléchargement / suppression des 
fichiers). En prenant note quand même qu’à partir du moment où un plugin 
est requis par composer, leurs chemins d’autoloading seront déclarés 
(que le plugin soit actif ou pas dans SPIP)

2) SVP (anciens sites)
----------------------

L’autre problème qui se pose… est la gestion des plugins des sites qui 
n’ont pas migrés à Composer. Ça serait bête qu’ils ne puissent d’un coup 
plus faire fonctionner le téléchargement de SVP. Ça sous-entendrait 
qu’il faudrait continuer à faire tourner l’outil smart paquets (et les 
fichiers archivelist) quelques années encore (combien de temps ? ...)
Ou trouver une méthodologie pour que ça puisse encore fonctionner, mais 
en s’appuyant sur les paquets du packagist (et là c’est pas gagné)


Sur GIT
-------

A) Core

Est-ce qu’on est d’accord pour passer le svn du core en Git ?
Est-ce gênant d’abonner l’URL svn du core ? ou est-ce que ça peut 
devenir un dépot
-- en lecture seule bloqué (mais les utilisateurs n’auront alors pas 
d’erreur indiquant que ce n’est plus à jour en faisant svn up)
-- en lecture seule synchronisé (unidirectionnel) sur le git (faisabilité ?)
-- en lecture/écriture synchronisé avec le git (comme déjà dit cette 
solution me paraît trop hasardeuse) (ce que propose azerttyu)

B) Plugins

Est-ce gênant de migrer des plugins sur Git ? (par exemple les 
plugins-dist du core ?), avec un peu les mêmes questions…

Si on déplace un plugin de svn à git (ce qui me parait plus facile que 
de tenter de synchroniser les deux), on obtient possiblement un autre 
problème pour générer les zips via smart_paquets (il faut au moins 
modifier les archivelist).


Sur les usages
--------------

Composer et Git modifieraient grandement les usages en basculant dessus.
Est-ce que notre petite communauté d’utilisateurs de la zone est prête à 
basculer ? J’ai le vague sentiment que oui (composer et git se sont 
largement démocratisés).

Ça nécessite tout de même de revoir grandement le Spip Loader pour 
l’installation facile sans terminal (mais dans ce cas là il faut que SVP 
puisse continuer à télécharger de lui même les plugins…).

Ou doit-on dire, maintenant, pour installer SPIP, il faut un accès shell 
? installer composer, et lancer le create… les require… ?
Est-ce que ça ne va pas un peu à l’encontre d’une simplicité/facilité 
d’usage que l’on souhaitait ?


Sur PSR
-------

Également je pense qu’il fau(dra) aller vers plus d’utilisation 
d’interfaces proposées par le PSR car elles servent de base à de 
nombreuses librairies PHP maintenant (Conteneur, Log), et il me semble 
dommage de ne pas s’interfacer naturellement dessus.

-

Je suis sûr que j’ai oublié des choses.

Bon, quand est-ce qu’on commence ?

Tendrement,

MM.
_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip