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

Le 06/03/2020 à 18:59, Matthieu Marcillaud a écrit :
> 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
Je crois qu'on n'est pas tout à fait non plus sur le même besoin, et 
donc pas sur le même cahier des charges.

Si je comprend bien ta perspective, toi tu envisage une amélioration 
drastique du système de distribution/d'install de paquet pour une future 
version de SPIP. Avec possibilité de choisir précisement la version du 
plugin qu'on veut installer, et en s'appuyant sur composer.

Moi j'ai un problème concret : avec la version actuelle de SPIP, comment 
est-ce que j'installe automatiquement via SVP un plugin qui est déposé 
sut git.spip.net ? Pour cela il faut qu'il soit dans le depot.xml standard.

Parce que là en gros on me dit : il faut pas mettre ton plugin sur svn, 
uniquement sur git. Mais pas moyen pour autant de l'installer. Ca veut 
dire qu'on fait quoi en attendant ?

Bref, je ne dis pas que ton travail est inutile, et je pense même le 
contraire. Mais c'est un travail sur du moyen terme.

_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip