Composer local pour les vendor

Dev
#1

Hop,

pas tapé, promis, j’essaie de comprendre !
J’ai voulu testé #5710 - Utiliser le composer `spip/cache` pour le cache des squelettes - spip - SPIP on GIT

voir mon rapport de tests là bas.

Ca à l’air cool.

Par contre j’ai voulu executer les tests unitaires sur le composant, juste pour le fun.
Donc

cd vendor/spip/cache

→ Pas de dossiers tests.

Bon aller

je me fais alors un

git clone git@git.spip.net:spip/cache.git

→ ouais j’ai les tests (et ils marchent).

Bon, là je me dis « mais comment diable avoir aussi les tests dans l’install via composer », et je me rend compte qu’en fait le vendor/spip/cache n’est pas un clone.
Et je me rappelle de la discussion d’il y a quelques semaines

Donc je tente

composer local install

→ nada, que puic.

J’imagine que composer n’est pas fait pour bosser nativement avec des dépots git ? Un truc que j’aurais mal compris quelque part ?

#2

J’ai essayé aussi, sur une install en SPIP5 déjà faite.

git checkout new_cache
composer install
rm composer.local*
composer local mode-dev
composer local install

Et pareil que toi.

Mais je viens de comprendre : composer local install ne met pas à jour le dépôt s’il est déjà là.
Pour ça qu’il faut faire un rm plugin-dist/* avant composer local install pour avoir les plugins dist en git.

Et donc, comme on ne peut pas supprimer tout vendor/* parce que la commande composer local en a besoin, on peut au moins supprimer par exemple vendor/spip/cache et refaire un composer local install qui cette fois va l’installer depuis les sources.

Et là, ça marche, on l’a bien en git, avec les tests.

(pfiou, c’était pas simple, mais on va y arriver)

#3

Par contre, les remotes des dépôts semblent être en https et pas en ssh, un truc qui m’échappe ?

[remote "origin"]
	url = https://git.spip.net/spip/medias.git

(…)

[remote "origin"]
	url = https://git.spip.net/spip/hasher.git
#4

Il faut relancer la commande mode-dev ensuite pour les avoir en ssh (tant que ce n’est pas déjà en git, il ne le propose pas)

#5

Par contre, les remotes des dépôts semblent être en https et pas en ssh, un truc qui m’échappe ?

yop, cf ce ticket spip-cli qui résume les commandes à faire, après que j’ai demandé à @marcimat comment avoir effectivement tout en SSH :

Bon va falloir écrire une doc :stuck_out_tongue:

Genre ajouter un chapitre « pour les devs (et pour SPIP 5) » à cet article en préparation :

Peut-être aussi qu’il faudrait corriger le script perso « local » de composer, pour pas avoir à le relancer bizarrement deux fois (et aussi qu’il supprime les plugins-dist lui-même si déjà présents, pour les remettre ?)

···

https://git.spip.net/spip-contrib-outils/spip-cli/issues/64https://www.spip.net/ecrire/?exec=article&id_article=6822

-- 
RastaPopoulos
#6

Oui, enfin, composer local on l’a ajouté parce que les gens ne s’intéressent pas trop au fonctionnement de Composer, mais en vrai, ça ne sert pas à grand chose si vous faites attention à ne pas commiter malencontreusement vos modifications du composer.* . Et donc notamment la modification que crée le mode-dev là de dire de télécharger les dépots spip/* en git.

Si ça parait trop alambiqué de gérer en plus un composer.local, autant l’enlever et dire aux gens de se référer à la documentation de Composer directement ?

#7

Ah oui ok, merci.
En fait la commande mode-dev fait plusieurs choses différentes.
C’est pas forcément intuitif mais quand on le sait, ça va mieux.

#8

Le dev web aujourd’hui c’est vraiment complexe en terme d’outillage, on ne peut pas être spécialisé sur tout.
Il me semble que le local / mode-dev que vous avez développé c’est une couche de plus haut niveau, que ça simplifie l’usage « avancé » de composer et que c’est plutôt bon à prendre, surtout si c’est amené à évoluer en fonction des retours et des usages.
Mais peut être je me trompe.

#9

attention, de ce que je comprends il ne faut pas confondre le mode-dev et le local. Actuellement c’est lié, mais en en soit pas besoin, on pourrait avoir un mode-dev directement sans le local.

Oui, enfin, composer local on l’a ajouté parce que les gens ne s’intéressent pas trop au fonctionnement de Composer, mais en vrai, ça ne sert pas à grand chose si vous faites attention à ne pas commiter malencontreusement vos modifications du composer.* . Et donc notamment la modification que crée le mode-dev là de dire de télécharger les dépots spip/* en git.

Il me semble que vu qu’on a reussi à se discpliner en passant par des PR, cette sécurité pourrait sauter (quite à en mettre une autre niveau forge, sous forme de tests lors desPR…)