Re: [SPIP Zone] Mise à jour git.spip.net

Oui alors, va quand même falloir arrêter avec cet argument de « si on est pas sur github on sera pas sur packagist et du coup les gens pourront pas installer leur package depuis composer sans faire des manips compliquées »

1/ on est d’accord sur le point 1 qu’il suffit d’avoir spip/spip sur packagist pour que tout le « composer create spip/spip » fonctionne et qu’ensuite sur un projet SPIP tu peux installer tous les packages que tu veux depuis packages.spip.net, sans aucune manip supplémentaire

2/ le cas hypothétique de « je veux que SPIP fonctionne dans vendor comme un composant sur un autre projet » on va l’oublier si tu veux bien, il y a des bonnes chances pour que composer soit has been mort et remplacé par autre chose avant que ça n’arrive - et si t’as pas d’accord, va directement au point 3

3/ le cas de la lib super générique qu’on veut pouvoir redistribuer autre part (comme TextWheel, souvenez vous, que d’émotion…)
Ma réponse n°1 c’est : quelqu’un qui est venu chercher une lib dans l’univers SPIP et veut l’utiliser n’aura pas trop de difficulté à ajouter la directive « repositories » dans son composer.json
Ma réponse n°2 c’est : hé, si on veut être visible c’est super simple : on ajoute dans le smart-paquet/ ou quel que soit l’outil qui le remplace, à chaque push ou mise à jour un
curl -XPOST -H'content-type:application/json' 'https://packagist.org/api/update-package?username=Spip&apiToken=API_TOKEN' -d'{"repository":{"url":"PACKAGIST_PACKAGE_URL"}}'
et pouf on a un package sur packagist à jour automatiquement.
Passer à Github pour éviter un curl, c’est quand même un peu le comble…

Et je rappelle que dans tous les cas, github ou pas, il faut aller soumettre chaque projet sur Packagist manuellement la première fois.
On ne trouvera donc que les packages qui auront été publié là-bas, dans une démarche volontaire et consciente (pas de magie)


Ensuite l’argument de « on n’est pas assez nombreux, maintenir nos outils ça nous tue », est à mon sens totalement hypocrite et mensonger.

Ce qui nous tue c’est de systématiquement tirer dans les pattes et freiner ceux qui font quelque chose, au pretexte que « si on faisait autrement ça serait mieux », le « on » n’étant en l’occurence jamais celui qui le prononce, qui se contente de dire qu’il aimerait autre chose.

Alors oui « on » pourrait faire autrement, mais « on » a déjà une forge git qui fonctionne, « on » peut commiter en git sur SPIP
(est-ce que je devrai suggérer que ceux qui n’ont même pas encore essayé de checkout SPIP en git et/ou de commit ou faire une PR devrait commencer par là pour avoir un avis éclairé à ce débat ?), « on » a un outil de conversion des projets de la zone vers git et cette forge

Et *je* ferai le super gros outil très compliqué qui curl packagist.org pour mettre à jour les packages composer si on est pas sur github, puisque c’est vraiment un point crucial dans tout ce débat.

Et donc j’ai du mal à voir pourquoi « on » devrait jeter tout le travail fait par Camille, qui est certes perfectible, à partir du moment où ça n’entrave rien.
Mais si « on » met la même énergie à tout faire marcher qu’à râler je n’ai pas de toute que tout ira bien.

--
Cédric
Le 9 août 2019 à 19:51 +0200, Matthieu Marcillaud <[email protected]>, a écrit :
> Le 09/08/2019 à 15:11, Cerdic a écrit :
> > Pour faire avancer le schmilblick (ou pas), je note quand même ici pour
> > les records que techniquement, seul le paquet principal root spip/spip a
> > besoin d’être sur Packagist.org et donc sur github
> > Car il peut ensuite déclarer le dépot https://packages.spip.net sur
> > lequel on retrouvera tout SPIP et la zone et tuti quanti
> > https://getcomposer.org/doc/04-schema.md#repositories
> >
> > Ça veut donc dire qu’on peut très bien avoir notre git et mirorer
> > simplement spip/spip sur github, [...] (ou alors j’ai pas bon ?)
>
> (je fais que passer)
>
> Alors sur ce point précis, oui, si tu lances «composer create-project
> spip/spip), afin de copier (entre autres) son composer.json à la racine
> de ton projet. La déclaration des repositories ne fonctionnent qu’à la
> racine.
>
> C’est à dire que si un jour quelqu’un·e tenterait soit :
>
> A) composer require spip/spip (ce qui le placerait dans vendor/, ça
> fonctionnerait pas (bon actuellement SPIP ne peut pas fonctionner de la
> sorte cependant)
>
> B) si quelqu’un veut simplement une librairie, un plugin de SPIP,
> "composer require spip/bidule" ne fonctionnera pas si son composer
> racine à lui n’a pas la déclaration du repository.
>
>
> MM.
>
> ----
> [email protected] - https://listes.rezo.net/mailman/listinfo/spip-zone