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

Hello,

Désolé de prendre un peu le train en route mais j'ai pas eu le temps de
répondre au moment opportun de chaque mail, donc je fais un peu un résumé /
patchwork.



Le ven. 6 mars 2020 à 21:18, Matthieu Marcillaud <[email protected]> a
écrit :

> Le 06/03/2020 à 20:21, Maïeul Rouquette a écrit :
>
> > 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.
>
> Oui (si tu parles de Composer directement), et non.
>
> Non parce que l’idée dans un premier temps surtout était bien de faire
> générer par l’outil un équivalent du dépot xml de SPIP, pour que ça
> fonctionne avec SVP justement.
>

En fait, je l'ai déjà expliqué il y a longtemps que SVP n'est pas un plugin
uniquement dédié à l'installation des plugins.
Il assure :
- l'installation des plugins
- mais aussi, et c'est essentiel, la *construction du référentiel des
plugins* c'est-à-dire les tables plugins et paquets.
- en outre, depuis peu, la gestion des catégories a été extraite de SVP qui
s'en chargeait jusqu'à SPIP 3.2.
C'est pour ça que j'avais proposé de séparer pour la 3.3 SVP en deux
plugins : "SVP Installation" et "SVP référentiel". On y viendra de toute
façon avec Composer car à terme il n'existera plus que SVP Installation
dans les sites sachant que SVP Référentiel ne sera utile que sur les sites
Contrib et Plugins SPIP. Je rappelle aussi qu'aujourd'hui il existe une API
REST sur le référentiel hébergé par SPIP Contrib (plugin SVP API) et qui
peut fournir toute information sur les plugins.

De fait, archives.xml construit par SP contient à la fois des informations
pour créer le référentiel (la majeure partie) et aussi des informations sur
l'installation (les necessite, procure, lib principalement).
Si on veut reconstruire même par étape cet écosystème il faut absolument
prendre en compte ces deux aspects et voir comment on peut justement les
séparer car c'est à mon avis le mélange actuel des deux qui amènent aussi
des problèmes complexes à résoudre.

Autre chose, l'idée de SVP et des ses "dépôts logiques" (les archivelist) a
toujours été de construire un référentiel commun à partir de dépôts
physiques hétérogènes et distribués. Tout n'a pas été fini car si SVP
permet de charger n'importe lequel des archives.xml on a jamais fait évolué
SP pour qu'il permette de générer les zips autres que de la zone. Donc
aujourd'hui ce qui est problématique et que j'ai mesuré aussi lors de la
refonte de contrib, c'est que pleins de plugins "n'existent pas" car il ne
sont pas générés par SP.
Donc, je sui tout à fait d'accord avec Cédric et Matthieu : la zone svn ou
git est un espace communautaire à privilégier mais il faut absolument
agréger les autres environnements de développement : le nouveau SP doit
donc être flexible et ne pas fonctionner uniquement pour le gitea SPIP.


>
> Ma démarche était
> - soit de repartir de smart-paquet, mais il faut intégrer tout le machin
> Git dedans, et ça ne marchera que pour SPIP et son depot.xml à terme
> (pas du tout adapté à Composer)
> - soit de partir de Satis (qui fait tout ce qui faut pour Composer déjà,
> est documenté et testé), en tentant de l’utiliser en attendant pour le
> format SPIP. Mais c’est aussi un chantier.
>
>
Je ne vois pas pourquoi on ne profiterais pas du travail déjà réalisé sur
Satis.
Je pense que c'est la bonne solution pour l'installation.
La question c'est quid du référentiel et c'est ça qu'il faut discuter :
quand je vois Matthieu s'étonner de voir des autorisations dans le
archives.xml on est en plein dans la problématique de l'installation vs le
référentiel. Non les autorisations ne sont pas utiles pour l'installation
(d'ailleurs on ne les a jamais affiché non plus) ni les traductions, ni la
taille du zip...

Donc conclusion je serais d'avis de poursuivre la piste Satis en
réfléchissant à la séparation installation / référentiel.
Mais je ne suis pas sur qu'il faille justement recréer un archives.xml tel
qu'aujourd'hui.
A voir.

++
Eric