Composer, Packagist, gitea, gitlab et github sont dans un bateau

Hello,

je fais un mail de synthèse de tout ça parce que c’est compliqué et JE suis très lent à la compréhension.

tl;dr: si tout mettre sur github.com+packagist.org est plus facile, ce n’est pas le plus efficace à long terme : avoir notre annuaire composer faciliterait la vie des contributeurs en automatisant le listing des paquets, et évite de recourir à github. On pourra alors utiliser packagist+un miroir github pour spip/spip uniquement et éventuellement les libs génériques qu’on veut promouvoir
A court terme, sans avoir notre annuaire, on peut utiliser packagist.org avec gitea - les installations se feront toujours en git, pas en zip, mais vu que ça concernera essentiellement les développeurs, est-ce dramatique ?


# Composer
le gestionnaire de paquet qu’on veut pouvoir utiliser a l’avenir

# Packagist.org

l’annuaire des paquets qu’on aimerait pouvoir utiliser à l’avenir pour les paquets SPIP. Parce que c’est l’annuaire des paquets par défaut de composer et si un paquet est déclaré là-bas composer va le trouver directement sans aucune difficulté. Sinon ça complique la vie des utilisateurs
3 scénarios possibles vis a vis de packagist :
- tous nos packages sont là bas, ça marche tout seul automagiquement, mais chaque paquet doit être déclaré manuellement une première fois sur packagist
- seul notre paquet SPIP/SPIP est la-bas, on a un annuaire de paquets à nous pour tous les autres paquets SPIP - ça marche encore a peu près magiquement pour l’installation de SPIP et des plugins du moment que le paquet SPIP/SPIP déclare notre annuaire à nous.
Il faut maintenir un annuaire hébergé chez nous, mais par contre il peut possiblement automatiquement choper tous les paquets de git.spip.net
- on a tout sur notre annuaire à nous : plus rien de marche magiquement, donc on veut pas ça

# Packagist.org et github.com
Ensuite c’est tout magique : si le projet est sur github packagist retrouve tout et tout marche à merveille, chaque fois qu’on pose un tag packagist se mets a jour automatiquement et le nouveau paquet est disponible

# Gitea et Packagist.org

Si le projet est sur gitea, il n’y a pas mise a jour du paquet automatique sur packagist, mais il faut déclencher la mise à jour en appelant une URL chez packagist. Un outil intermédiaire à mettre en oeuvre, mais rien de compliqué. Surtout qu’on peut mettre un webhook depuis gitea, qui appelle notre outil, qui curl packagist.org

MAIS, il y a un mais, packagist ne connait pas gitea, donc il ne sait pas référencer les zip générés par gitea dans son .json, et du coup composer ne peut downloader les paquets qu’au format .git, et pas au format zip
De ce côté là aucun palliatif connu, sauf à mirorer le projet sur github depuis gitea

# un Gitlab (auto-hébergé) et Packagist.org

Même si packagist et/ou composer connaissent l’API gitlab, ça marche comme pour le gitea auto-hebergé : au final les downloads se font au format .git et pas .zip

# Gitea et Un annuaire composer perso SPIP

A la place de mettre tous les plugins SPIP sur packagist.org, on peut donc avoir un annuaire SPIP des packages composer.
Ça peut être un Satis tweeké ou même notre propre outil.
L’inconvénient c’est donc qu’on doit maintenir ça - mais c’est plutôt plus simple que le smart-paquets qui tourne actuellement
L’avantage c’est qu’il pourrait donc
* attraper automatiquement tous les paquets de git.spip.net qui ont un composer.json et les référencer, sans nécessiter d’aller déclarer manuellement chez packagist.org chaque paquet,
* gérer les mises à jour auto également, en le branchant sur un webhook qui va bien
* référencer les zip générés par gitea


Donc en synthèse :
Tout mettre chez github a une part de simplicité vis a vis de composer, au prix d’une certaine dépendance, mais obligera a toujours aller déclarer manuellement chaque paquet, a charge pour chaque développeur d’aller le faire (mais on peut considérer que ça remplace archivelist)

Choisir Gitea comme forge n’est pas bloquant pour l’avancement du projet composer a court terme :
- on peut référencer manuellement les paquets sur packagist aussi, mettre en place le webhook pour l’autoupdate, et ça permet de travailler. Seul inconvénient pour le moment, on aura pas des zips mais des clones quand on fera des instal avec composer.
C’est plus lent, mais pas forcément plus mal car a court terme ça ne concernera que les developpeurs ou pour générer les paquets de distribution spip
Si ça nous embête vraiment on peut mirorer les projets concernés sur github et packagist utilisera automatiquement les zips de la-bas même en continuant à référencer le projet comme étant chez git.spip.net

Et à moyen terme pour généraliser l’utilisation de composer sur la zone, ça semble de toute façon pas plus mal d’avoir notre annuaire composer, que ce soit un packagist, un satis ou un outil maison (qui consiste en gros a faire avec les composer.json ce qu’on fait actuellement avec les paquet.xml pour plugins.spip.net)
Annuaire qui pourra alors référencer automatiquement les plugins de la zone disposant d’un composer.json, et distribuer les zips du gitea, effaçant l’inconvénient ci-dessus avec un avantange de facilité pour les utilisateurs.
Seul le paquet spip/spip aura besoin d’être sur packagist.org et miroré sur github, se chargeant alors de déclarer l’annuaire spip dans lequel composer pourra aller chercher tout le reste.

Pour des libs génériques qu’on voudrait promouvoir à l’extérieur de l’univers SPIP et publier sur packagist.org on pourrait aussi alors devoir mirorer sur github.
Tout ça en supposant que rien ne progresse (les possibilités de packagist et/ou l’interoperabilité de gitea)



--
Cédric