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 <marci...@rezo.net>, 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.
>
> ----
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à