Re: Proposition pour la génération de archivelist

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.
_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip