Hello,
> J'ai donc produit une v2 du cahier des charges suite aux différentes
> remarques.
>
> https://git.spip.net/spip-contrib-outils/archives_from_gitea/src/branch/master/README.md
Alors, moi je ne partage pas entièrement ce cahier des charges déjà
- ça serait bien de s’approcher de ce que font Packagist ou Satis : tu donnes l’URL du dépot GIT, il se débrouille avec ça pour créer la liste des paquets / versions possibles, stocke les zips des tags, permet de récupérer quand même les branches à jour (@dev-master) si besoin, etc...
- ça limite à Gitea, alors que d’autres projets peuvent être ailleurs, de façon temporaire ou non. Et je trouve ça assez dommage de s’en priver ; non ?
## Satis
J’avais commencé à regarder / détourner Satis
Satis sert à générer des dépots Composer, c’est à dire un fichier .json (enfin plusieurs, mais bref) un peu comme notre https://plugins.spip.net/depots/principal.xml qui liste des paquets et leurs versions, avec les chemins pour les télécharger.
Si on va réellement vers l’idée d’utiliser Composer à terme, tout en restant sur git.spip.net (donc pas Packagist.org directement), il faudra faire générer un dépot Composer adéquat, il faudra utiliser Satis, ou un packagist à nous, ou réécrire la roue...
Si on arrivait à avoir un outil, pour notre problème actuel, qui s’appuie sur Satis, avec à peu près la même configuration, la transition serait peut être plus simple (une fois que SPIP utilise Composer, on bascule sur Satis sans surcharge...). À vrai dire j’y crois moyennement car ça va hurler (pas de traduction, pas de logo dans les composer.json ...) ; mais c’était l’idée.
### Fonctionnement Satis
À Satis, on lui donne une liste de dépots git (github, gitlab) (il ne sait pas bien faire avec Gitea par défaut), il les analyse en cherchant leurs fichiers composer.json dans chaque branche / tag et s’il en trouve décrit alors le paquet, et si c’est un tag, télécharge ou crée le zip localement (selon les possibilités du driver (github, gitlab, ...) / api utilisée)
Bref, Satis :
- ne fonctionne qu’avec des fichiers composer.json.
- collecte localement les zips des tags (mais pas des branches)
### Détournement Satis
Ce que j’ai commencé, début janvier (puis j’ai fait d’autres choses donc c’est stand by) c’est un outil qui s’appuie sur Satis (qui lui même s’appuie sur Composer), mais qui surcharge certains de ses comportements.
1) j’ai ajouté un driver Gitea (partiel) ; au moins il sait récupérer des fichiers et des zip en passant par son API
2) je «fake» un fichier composer.json virtuel s’il n’en existe pas dans la branche / tag ... Actuellement c’est très rudimentaire, mais l’idée était d’analyser paquet.xml / plugin.xml / lang/ pour obtenir quelques infos en plus)
Avec cela déjà ça stocke localement les zips des tags des dépots concernés. (et ça crée le fichier de dépot composer, totalement inutile pour nous).
C’est là où j’en étais.
Mon idée était donc pour continuer :
- d’analyser paquet.xml (etc.) pour améliorer le faux composer.json
- d’ajouter un export «principal.xml» qui génèrerait l’équivalent, si c’est possible, de ce qu’on avait auparavant.
Mais déjà dans mes tests, j’ai vu quelques problèmes :
- Satis fait appel aux APIs des drivers pour obtenir le fichier composer.json de chaque tag (déjà c’était long), mais s’il le trouve pas, il va falloir analyser paquet.xml, plugin.xml, lang/ ce qui va faire beaucoup d’appels et risque d’être encore plus long. Composer (et consœurs) ne s’appuient que sur 1 seul fichier, c’est peut être pas pour rien.
- Pour dire à Satis de ne réanalyser que "spip/medias" par exemple, ça sous-entend que :
-- soit on a déclaré en amont "spip/medias" dans la liste des dépots git à traiter (donc son "name" en plus de l’url de GIT),
-- soit Satis doit analyser l’ensemble des dépots listés (via leurs composer.json) pour déterminer lesquels ont "spip/medias" dedans ce qui est aussi très long.
Du coup, il semble judicieux de déclarer systématiquement la déclaration "name" en plus de l’url, ce qui ressemble à :
{
"type": "vcs",
"name": "spip/medias",
"url": "https://git.spip.net/spip/medias"
},
Et on ne peut pas alors déclarer 2 fois le même "name".
Voilà, j’étais là… puis j’avais regardé la tête d’un fichier d’un dépot xml chez SPIP, et vu des balises `<autorisations>`… je m’étais demandé pourquoi parbleu ces trucs étaient dedans alors que ça sert nul part… et…
Puis je suis allé faire de la musique…
MM.
J'ignorais juste qu'il était en vacances. De même je compte attendre l'avis d'Eric.
