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
Hello !
à tester :
et
qui sont sous-tendues par Up down extensions (!9) · Requêtes de fusion · spip-league / composer-installer · GitLab
Je viens de tester ce qui suit :
checkout spip -b4.4 spip
cd spip
git co up-down-extensions-4.4
composer install
composer spip:extensions:switch-forward
Ok, les plugins-dist sont bien déplacés dans un sous rep spip et un git st` donne :
Sur la branche up-down-extensions-4.4
Votre branche est à jour avec 'origin/up-down-extensions-4.4'.
Modifications qui ne seront pas validées :
(utilisez "git add/rm <fichier>..." pour mettre à jour ce qui sera validé)
(utilisez "git restore <fichier>..." pour annuler les modifications dans le répertoire de travail)
modifié : composer.json
modifié : composer.lock
supprimé : plugins-dist.json
Puis composer spip:extensions:switch-back fait son job mais je me retrouve avec le dossier plugins-dist vide. Peut-être aurais-je du annuler les modifs locales aux fichier avant de lancer la commande ?
Bref, dispo quand tu veux pour tester en suivant le bon chemin 
1 « J'aime »
Quand tu fais un back, composer enlève ce qu’il ne gère plus. Tu reviens à l’utilisation précédente à savoir avec checkout… et composer ne gère pas checkout … 
Tu reprends la main avec ton outil précédent
Donc faut que tu relances checkout 
Je l’ai écrit dans le fichier docs/plugins-dist.md · main · spip-league / composer-installer · GitLab
Je viens de faire une install, avec 2 changements par rapport à @b_b :
spip dl -b 4.4 -d spip44- avant de changer de branche, j’ai finalisé mon installation et je me suis rendu sur la page des plugins verrouillés.
- ensuite, j’ai finalisé le switch de branch (comme @b_b)
Quand je suis revenu sur ma page de plugins, j’ai eu cette erreur :
Si je vide le cache, l’erreur disparait.
1 « J'aime »
Je regarde ça ASAP
il y a régulièremnet des problèmes avec le cache de tw lors des mises à jour, y compris avec les « anciennes methodes »
Intéressant, je prends ça en note.
Si je trouve une méthode pour vider ce cache de textwheel à l’install/update, je pense qu’il faudra l’intégrer au processus…
enfin je sais pas si c’est le cache de tw ou le cache ET tw. Mais régulièrement lors de mise à jour, on a cw problème d’include once, comme si quelque part les chemins restaient collés.
Ça semble être plus un pb avec ue constante _DIR_PLUGIN_TW en effet…
Et la « bonne nouvelle », si on peut dire, c’est que j’ai reproduit le même message d’erreur que @tofulm …
Et donc, c’est pas le cache de plugins, mais bien dans le cache textwheel qu’on trouve un quelquechose.
les « wheels » peuvent « require » un fichier php, fournit par SPIP en tant que chemin relatif. Puis les wheels sont cachées dans tmp/cache/wheels sous forme sérializées (PHP)
Et ce sont notamment les wheels du dossier plugins-dist/textwheel/wheels/ qui sont cachées. Quand on passe de plugins-dist/textwheel à plugins-dist/spip/tw, évidement, le chemin « require » sérializé en PHP n’existe plus…
Je corrige ça ASAP !
3 « J'aime »