Un composer create-project n’y change rien du tout.
Il faut supprimer vendor et refaire un composer create-project ?
Ou bien composer install d’ailleurs ?
Idem, si j’ai fait un composer create-project mais sans--keep-vcs --prefer-source, j’ajoute après coup les deux configs, je supprime ecrire, prive, plugin-dist et vendor, et je relance composer pour qu’il réinstalle depuis les sources.
Et j’ai bien tout spip/* en git.
Je continue à tester des trucs de mon côté, tout en lisant la doc de Composer sur les versions, notamment la partie sur les branches.
Dans les exemples que tu donnes où tu précises une version, on se retrouve en git en état détaché sur un tag.
Pour rester sur la branche, il faut par exemple utiliser 4.4.x-dev au lieu de ^4.4.
Si j’ai bien suivi, on ajoute arbitrairement un -x au nom de la branche pour que composer reconnaisse que c’est pas un tag (?) et on suffixe -dev, alors que pour des branches sans numéros on préfixe juste dev-.
Pourquoi un .x puisqu’on a une branche 4.4 mais pas de tag du même nom ?
Mystère, et j’ai plus de Doliprane sous la main.
Mais si on veut juste être en HEAD sur la branche, le plus simple c’est pas de faire juste un clone et install :
git clone https://git.spip.net/spip/spip.git
git switch ce_qu_on_veut
composer install
...la suite
Je ne sais pas si le « tu » s’adresse à moi ou a marcimat ou une autre personne. Je découvre tout autant que toi ce monde de composer.
Mais effectivement dans le composer.json de SPIP ont pointe vers des dépendances, et composer va ensuite chercher le tag satisfaisant la dépendance.
Car composer n’est pas prévu pour développer « les paquets individuels au sein d’un grand tout » mais pour installer ces paquets.
Et l’enjeu au niveau du composer.json de SPIP, c’est d’aller chercher les bon tags des bon paquets pour pouvoir installer un SPIP, pas (prioritairement) de dev des paquets SPIP.
Si on veut dev SPIP, on fait quoi, on modifie ces require pour spécifier là aussi des branches, dans composer.local.json ?
je pense que c’est là qu’il y mécompréhension. Ce n’est que pour des raisons Historiques qu’on peut dire « on veut dev SPIP ». En réalité il faudrait plutot dire « on veut dev des composants qui servent dans SPIP, et qu’on ne bien développer actuellement qu’en ayant un SPIP complet ».
Pour ma part lorsque je veux travailler sur un composant de spip tout en ayant un SPIP complet.
je crée le projet en keep-vcs
je me rend dans le composant concerné
je bascule vers la branche concerné
Maintenant, rien n’excluerait (mais faut le faire) je pense de proposer un projet SPIP-dev, qui, comme tu le suggère, pointerai vers des branchs et non des tags.
M’est-avis qu’il faut surtout mettre à jour SPIP-Cli pour que l’option « dev » prenne en compte tous les nouveaux changements et se place sur les bonnes branches (en plus de bien mettre en SSH, Git etc). Tout ça en une seule unique commande à se souvenir, et non pas 15 trucs à lancer que personne ne se souviendra de tête (s’il faut lire un readme à chaque fois qu’on veut installer ou mettre à jour…)
Le « tu » s’adressait à toi comme auteur du post / tuto initial, mais il était assez générique en fait.
Et j’en arrive à la même conclusion après avoir déroulé tout ça.
Sauf que, les noms des branches des composants (ecrire, prive, plugins-dist) ne suivant pas celles de spip/spip ni entre elles, c’est un niveau d’embrouille de plus…
Je répondais à ton message, et donc à ta conclusion : checkout la branche qu’on veut dans le projet sur lequel on veut travailler.
Mais c’est quand même vachement moins pratique qu’un simple spip dl ou checkout, et surtout beaucoup plus casse gueule.
Et éventuellement un jour de proposer un project SPIP-dev comme tu dis, mais je n’ai pas trop le temps de creuser dans ce sens là.
Je sais bien que ça a été décidé y’a longtemps, j’avais déjà émis cette crainte à ce moment là.
Et je voulais relire ce tableau et te répondre mais y’a pu d’électricité dans la forge…
Je ne le découvre pas, je mets juste concrètement les mains dans le cambouis maintenant pour développer SPIP, nuance.
Mais je m’attendais effectivement à ce merdier, pour avoir été dès l’origine attentif aux explorations de @JamesRezo sur SPIPremix (https://spip.lerebooteux.fr/) depuis 2018. Et pour cause…
(ce qui explique, au passage, que mes râleries ne sont pas apparues ex nihilo)
Dans un monde magique, tout serait bien fait du premier coup, et SPIP
utiliserait correctement Composer,
aurait tout son code dans vendor/ découpé en librairies
ses assets copiées dans public/
un unique point d’entrée public/index.php
Mais SPIP a une longue histoire, et toujours beaucoup de code qui date quasiment de sa création, et par là même, ça rend complexe en temps, en énergie, en volonté les transformations dedans.
Le découpage qui a été fait dans cette étape est lacunaire certes, mais il permet déjà d’avancer un peu dans une direction : utiliser Composer pour gérer les dépendances. Il n’y a plus un seul outil qui n’utilise pas Composer.
Alors oui, ça oblige à des contorsions pour faire « comme avant », « pour les devs »… ce n’est pas insurmontable d’une part, et d’autre part, je ne vois pas comment SPIP peut se maintenir en vivant, en PHP, sans cet outil.
Oui, mais note bien que je ne remets pas en cause, là.
Au contraire même, je m’y frotte concrètement, même si ça pique (pour moi).
Mais c’est comme avec les orties, je finirai par trouver le truc pour que ça pique moins, parce que c’est bon les orties
Oui je reprenais l’image de @Nicod.
Ce fil de discussion sur create-project me fait craindre d’être exclu de facto de la compréhension et du développement de SPIP 5. Un peu comme si j’allais devoir faire marcher qqchose que je ne comprend pas et suis incapable de réparer.
C’est pareil avec pas mal de technologies autour de moi (mon ordi par exemple), au moins en pratique et concrètement, car souvent j’en pige quand même les grands principes.
Mais que ça arrive à SPIP est inconfortable pour moi, comme les orties.
Alors lisant que c’est en partie une transition biscornue due à la nécessité de faire avec le long-long historique de SPIP, je m’intéresse de savoir si une fois la transition passée, il est envisagé que SPIP mûri et transformé revienne, parce que ce sera alors possible, à quelque chose plus d’équerre, à nouveau plus simple et qu’il me sera possible d’appréhender.
D’où ma question, ici un peu reformulée : « Est il prévu à terme de continuer/d’achever la mutation en évoluant vers quelque chose de à nouveau plus accessible ? »
Bah dans l’idéal oui, on irait vers un système où SPIP respecte toutes les conventions PHP existantes. Et donc où il suffirait de lire de la doc et des tutos PHP pour appréhender SPIP. Mais on est pas encore là, loins sans faux.
Pour revenir aux problèmes / questions de nicod, j’ai eu récemment à me reinstaller un SPIP de dev « neuf ».
La série de commande que j’ai faites, dans l’ordre :
composer global config "preferred-install.spip-league/*" source # Une fois pour toute, permet de toujours choisir les composants spip en git
composer global config "preferred-install.spip/*" source # Une fois pour toute, permet de toujours choisir les plugins-dist / ecrire / prive spip en git
composer create-project --repository=https://get.spip.net/composer --stability=dev --keep-vcs spip/spip # A chaque fois 1. Chercher spip/spip dans le depot composer de spip 2. Prendre la version dev 3. Utiliser git
cd spip
composer local mode-dev --no-interaction # Pour transformer les https en ssh au niveau des urls git
Puis se rendre dans le composant concernée, git checkout « la branche qui nous intéresse » et faire les modifs, puis commit et push
