Cette commande (composer create-project spip/spip par exemple) permettrait de créer un dossier spip prêt à l’emploi.
Si une autre distribution spip existait, les commandes composer create-project spip/autre-distribution ou composer create-project autre/distribution permettrait d’installer un SPIP avec une autre collection de « plugins-dist », d’autres jeux de « squelettes-dist » …
Mais pour cela, la toute première étape serait de déplacer le dossier ecrire dans un nouveau dépôt git et de l’enlever du dépôt spip/spip comme cela a été fait pour prive/ (Cf. Sortir le dossier prive/ de spip/spip)
Et, exactement comme pour prive/, il serait possible de ne le faire que pour les milestones qui nous intéresse, par exemple pour SPIP5 et SPIP4.4, avec une opération de déplacement des issues et des branches servant à des PRs en cours ou en préparation sur ces milestones.
Le plugin composer de SPIP est déjà prêt à fonctionner sur ce modèle.
Il faudrait alors adapter le système des mises à jour des fichiers de langue pour pointer vers le nouveau dépôt d’ecrire/.
Concernant les outils de release actuels, ils pourraient être adaptés pour générer les zips SPIP en se basant sur cette commande. Et si nous progressons sur le chantier « release gitlab », la CI pourrait le faire aussi.
Concernant spip_loader il n’y aurait pas d’impact.
Reste à voir quels seraient les impacts pour d’autres outils comme checkout ou spip-cli.
En tout cas, avec ça, le dépôt spip/spip ne contiendrait plus que les dossiers de base, comme config/, IMG/, tmp/ et local/ ainsi que les fichiers à la racine.
Dernier avantage, peut-être un peu déroutant : create-project peut fonctionner pour rester synchro en git avec le dépôt « racine » (chez nous, ce serait spip/spip) OU en mode « désynchro », ce qui fait que les dossiers/fichiers de base « appartiendraient » à l’utilisateurice qui pourrait alors les versionner dans un dépôt à ellui, soit pour créer une distribution ou pour versionner ses personnalisations d’un site particulier.
Ce serait cool d’avoir ça pour les sorties de 4.4 et 5.0, mais d’abord : Avez-vous un avis, des questions ?
ça serait mis à jour dans la limite max prévue par le JSON racine, mais qui du coup lui ne serait plus mis à jour ensuite (par défaut), à part à suivre les évolutions manuellement. C’est d’ailleurs le point le plus à suivre si on désynchronise et qu’on doit le tenir à jour manuellement (quelles branches pour chaque sous projets obligatoires de la dist).