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.
++1