Re: [SPIPremix] Une distribution SPIP alternative

Le 03/07/2018 à 23:25, spipfactory a écrit :
> Bonsoir,
[...]
> Donc ne changer rien et ce qui est a la mode aujourd'hui passera demain.

Bon OK ;
On ne change rien ; ça on sait déjà bien faire :)

Les dernières versions du loader sont visiblement bien appréciées 
(auto-congratulons-nous). Je vous rappelle que son code est sur la zone 
si vous voulez qu’il crée les répertoires plugins/auto, lib, squelettes 
manquants…). Y a pas d’obstruction…

Ceci étant dit, deux points :


1) sur la mode.

Je pense que non, cela n’a rien d’une mode ! Désolé ; la communauté PHP 
a mis un temps fou à s’organiser pour trouver une solution acceptable et 
acceptée d’organisation des librairies partagées pour dire «tatata, 
c’est une mode» …

Tu n’as pas un seul nouveau projet qui se dirait : tiens nous on va 
faire du code pas objet, sans réutiliser de librairies packagées, sans 
utiliser Composer, sans suivre quelques suggestions PSR.

L’histoire personnelle de SPIP est comme cela, certes, mais faut-il 
continuer ?

Je vais tenter de faire une relation avec les plugins de SPIP. En tant 
qu’utilisateurices, on est content·e·s de voir des supers plugins naître 
ou évoluer.

Savez-vous que régulièrement, un plugin va utiliser, en sous-jacent, des 
librairies php existantes. Figurez-vous qu’actuellement on est 
profondément embêtés quand on veut utiliser une librairie récente de la 
communauté PHP : celle-ci déclare quelques fichiers à elle, et ses 
dépendances (à d’autres librairies), comme le feraient nos propres 
plugins. Du coup comment intègre t-on cette librairie dans notre plugin 
? on copiant la lib + toutes ses dépendances. Qui sont probablement les 
mêmes que les dépendances d’un autre plugin SPIP intégrant une autre 
librairie… On se retrouve avec possiblement plein de fichiers en 
doubles, de multiples autoloaders à éventuellement charger, du code 
dupliqué, des mises à jour compliquées.

Quelques exemples dans la zone :
- 
https://zone.spip.org/trac/spip-zone/browser/_plugins_/extraire_documents/trunk/lib
- 
https://zone.spip.org/trac/spip-zone/browser/_plugins_/geoip/trunk/lib/vendor
- https://zone.spip.org/trac/spip-zone/browser/_plugins_/http/trunk/vendor
- 
https://zone.spip.org/trac/spip-zone/browser/_plugins_/owncloud/trunk/lib/SabreDAV/vendor

On cherche aussi une solution à ce problème. (c’est ce que faisait la 
déclaration de librairie à télécharger dans nos paquets.xml, sauf que ça 
ne marche plus avec les libs récentes, c’est pour ça qu’on est obligé de 
les «inclure» dans un répertoire lib/ ou pas des plugins ; et c’est pas 
vraiment génial).


2) sur Composer vs Loader

Je vois difficilement comment concilier les deux.

On peut évidemment faire un loader qui chargerait un zip de SPIP (issu 
d’une installation composer). Mais ensuite ? L’intérêt de composer c’est 
qu’un plugin (spip) puisse dire dans son composer.json qu’il nécessite 
telle ou telle librairie PHP. Et installer ce plugin, via composer, 
installerait toutes les librairies manquantes dans le répertoire vendor/.

Et ça c’est difficilement compatible avec SVP (qui télécharge les 
plugins depuis une interface graphique) ou avec le Loader, qui si on 
fournit un zip de SPIP aurait déjà un répertoire "vendor" avec un 
certain contenu, un fichier composer.json racine différent, et ça 
pourrait écraser du coup nos modifications…

Il n’existe pas de méthode pour utiliser Composer depuis des interfaces 
graphiques (sans fichier composer.lock, le calcul des dépendances prend 
trop de mémoire entre autres choses) et ajouter un plugin nécessite 
forcément de recalculer ce fichier composer.lock)

Alors du coup ?

Faut-il abandonner l’idée ?
Faut-il poursuivre dans cette voie (avec les conséquences) ?
Faut-il faire une fourchette ? (ie: faut aller jouer ailleurs ?)

Chaleureusement,

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