Comme avec SPIP5.0, comme pour le dossier prive/, mais comme il était déjà externalisé, aucun impact si vous utilisez checkout (ou déjà composer …)
PS: Il n’est pas prévu d’appliquer cette méthode avec les plugins-dist pour SPIP4.4.
1 « J'aime »
Je précise : on pourrait, mais cela a un impact sur le chemin des plugins-dist : au lieu d’être plugins-dist/X, ça deviendrait plugins-dist/spip/X (comme dans SPIP 5) et du coup une mise à jour SPIP 4.3 → 4.4 serait un peu plus touchy.
Je sais que James aurait bien aimé pourtant que les plugins-dist soient aussi chargés via Composer en SPIP 4.4 : si c’est le cas, il faut s’assurer que la migration se déroule facilement (via ftp, spip-loader, checkout, spip-cli)… et, à part spip-loader qui va effacer les contenus obsolètes, pour les autres, il faudrait le faire «à la main», ce qui semble ennuyant pour une mise à jour mineure.
C’était pour cette raison que je n’étais pas très chaud à reporter ce changement sur la 4.4.
Mais il y a peut être d’autres avis : parce que cela a le mérite
- d’avancer vers l’usage de Composer et
- de simplifier aussi le futur passage de 4.4 à 5.0
- d’homogénéiser un bout de fonctionnement entre 4.4 et 5.0
Des remarques ?
Même avis 
checkout et spip-cli ca pourrait s’automatiser non ? il y aurait guère que ftp. C’est vrai que cela arrive encore d’avoir des gens qui installent en full ftp…
je suis partagé.
1 « J'aime »
Question bête, ne serait il pas possible de proposer les 2 solutions ? (avoir on non le sous dossier spip)
Cela pourrait permettre de valider à plus grande échelle son fonctionnement et serait limité à des power user ?
1 « J'aime »
On peut y réfléchir, en effet.
Dans une spip 4.5
Ça rime avec 5
C’est bien évidement possible. Et même déjà possible…
Le point d’achoppement « technique », c’est la présence du dossier ecrire/ dans le dépôt spip/spip. Les restes des échanges sur pourquoi et comment faire sont là : Résultats de recherche pour « spipremix » - Discuter de SPIP (la migration vers discourse a parfois manger les mails initiaux …)
En l’état, solution la moins disante, il faudrait modifier le fichier composer.json à chaque fois qu’on souhaite basculer d’une installation à l’autre.
C’est possible de conserver l’état d’une installation avec l’utilisation du modificateur local du plugin composer de spip. Ça demande de jongler avec des fichiers, le cache de spip, et quelques manipulations basées sur des rm -rf ... Voire la composerisation de seenthis par exemple.
Il est possible de faire mieux, en changeant de braquet :
- isoler le dossier
ecrire/de l’arborescence de base (les dossiers créés lors d’ungit cloneou d’une installation parspip_loader:config/,IMG/,local/,tmp/, les fichiers de base comme./spip.php, …). - multiplier les « distributions » : des dépôts indépendants contenant au minimum un fichier
composer.jsonpour installer un SPIP différents dans l’organisation de son arborescence et/ou dans sa fourniture de plugins.
Mais alors là, le point d’achoppement devient humain … ça va troller …
c’est tout de même un peu trop ésotérique pour faire un gros buzz
