Mais tu avais dit que pour SVP (et même pour plugins.spip complet) yavait pas besoin aussi des infos « techniques » non ? pipelines, menus, etc, seulement les necessite et auteurs-crédits ? Bon c’était plus mineur certes.
Après yavait la solution évoquée aussi de « seulement ceux compatibles 4 et + »… Là ça diminue drastiquement.
Dans la version 5,6M 21 déc. 00:37 archives.thin.xml c’est enlevé oui déjà. Donc là je vois pas trop pour faire mieux, sinon à enlever certaines traductions dans les slogan, descriptifs…
Les autres pistes c’est oui,
En première approximation (en repartant de l’outil rapide), c’est
| Étape | Action | Fichier de sortie | Taille | Archives conservées |
|---|---|---|---|---|
| 0 | Source | archives.xml | 9,2M | 3753 |
| 1 | Supprimer les <archive dtd=plugin>…</archive> |
step1_no_plugin.xml | 8,1M | 3140 (613 supprimées) |
| 2 | + Supprimer <traductions>…</traductions> |
step2_no_traductions.xml | 7,1M | 3140 |
| 3 | + Dans <paquet> supprimer pipeline/menu/onglet/chemin/traduire |
step3_paquet_stripped.xml | 5,8M | 3140 |
| 4a | Garder seulement “au moins compatible SPIP 4.4” (max(compat) ≥ 4.4.0) | step4_ge_4_4.xml | 1,9M | 1045 |
| 4b | Garder seulement “au moins compatible SPIP 3.2” (max(compat) ≥ 3.2.0) | step4_ge_3_2.xml | 5,3M | 2857 |
| 4c | Garder seulement “au moins compatible SPIP 4.0” (max(compat) ≥ 4.0.0) | step4_ge_4_0.xml | 3,9M | 2070 |
Je continue dans les étapes 4, en nettoyant les lignes vides que ça générait (mais le gain est minime
Également avec une version couverte par l’intervalle du paquet
Précisions, ici le nombres d’archives indiquait bien le nombre de tags pour cette version, pas le nombre de plugins compatibles avec la version. Mais ça donne ça si on veut savoir:
| Fichier | Poids | # archives | # paquets (total) | # prefix uniques |
|---|---|---|---|---|
| covers_4_4.xml | 1,8M | 1043 | 1043 | 726 |
| covers_4_3.xml | 1,8M | 1041 | 1041 | 724 |
| covers_4_2.xml | 2,8M | 1573 | 1573 | 714 |
| covers_4_1.xml | 3,0M | 1658 | 1658 | 703 |
| covers_4_0.xml | 2,7M | 1570 | 1570 | 687 |
| covers_3_2.xml | 2,9M | 1727 | 1727 | 758 |
| covers_3_1.xml | 2,3M | 1334 | 1334 | 667 |
| covers_3_0.xml | 1,8M | 1032 | 1032 | 566 |
Pour être sûr de comprendre, quand tu dis ok pour 4.0 c’est tous ceux qui sont ok pour cette version précisément (mais pas uniquement), genre ceux qui sont [3.2; 4.*] et [4.0;5.*] etc.
Mais si on décidait de garder « tous ceux qui marchent sur des versions 4.X » ça permet pas trop de savoir, car ça comprendrait ceux qui sont [3.2;4.1] (pas plus que 4.1 mais ça marche bien sur des 4.0 et 4.1) et ceux qui sont [4.4;5.*]
L’intérêt de cet entre-deux (plutôt que juste ceux qui marchent en 4.4) c’est que ça vire tous ceux qui vraiment ne marchent que en 3.X qui n’ont jamais marché du tout sur une 4. Et ça garde donc ceux qui sont potentiellement « facilement » mettable à jour/utilisable en 4.4 quand même (ya déjà le « step » d’avoir marché sur une 4 de passé). Bon en plus la majorité de ceux en 4 ont déjà eu des modifs pour mettre « 4.* » en max…
Dans covers_4_3.xml tu a ceux qui marchent pour spip 4.3, sans qu’on se pose la question de savoir s’ils marchent aussi ou pas pour des versions spip 4.2 et < et pour des versions spip 4.4 et >.
A mon sens, il serait intéressant d’avoir chacun de ces fichiers archives.covers_x_y.xml disponible, en plus du archives.xml. On pourrait « relativement facilement » modifier l’url appelée par svp lors de ses mis à jour pour préciser ce covers_x_y.xml.
Et ça garde donc ceux qui sont potentiellement « facilement » mettable à jour/utilisable en 4.4 quand même (ya déjà le « step » d’avoir marché sur une 4 de passé
c’est un peu relativement peu intéressant pour ce qui nous concerne. Rappelons que l’enjeu c’est d’alléger ce que lis svp. Or SVP est prévu pour l’installation en interface graphique. Si un plugin n’est pas marqué compatible SPIP 4.4, tu ne peux pas l’activer en SPIP 4.4 sans le modifier (exception peut être de la constante pour forcer la compatibilite). Donc le fait que svp sache son existence n’est pas très utile.
Pas certain de tout comprendre ce que tu exprimes. Mais oui les covers_4_1.xml là ont bien les paquets avec « genre ceux qui sont [3.2; 4.*] et [4.0;5.*] etc. »
Si tu veux la liste de plugins qui sont compatibles 4, quelque soit la branche de ton SPIP, ça donne ça :
Si c’était la question
A été évoqué sur discord le fait de supprimer les descriptions des paquets.
Je suis parti de archives.thin.xml d’hier et j’ai fait un script python un peu brutal qui recopie tout, sauf si on est entre <description> et <description>. On gagnerait environ 25 %. Pas négligeable, mais du coup on perd la possibilité de rechercher la description d’un plugin pour en trouver un.
Donc la question est : est-ce que les gens lorsqu’iels installent un plugin via svp cherchent par nom (auquel cas faire sauter la description n’a pas de souci) ou bien par mot clé de fonctionnalité (auquel cas cela voudrait dire qu’il faut garder les descriptions). Je suis mitigé.
Je viens d’ajouter la possibilité d’avoir des fichiers de depots limités à une branche de spip.
En me tenant uniquement à spip-contrib-extensions (donc sans spip-contrib-squelettes) j’obtiens
Donc on aurait un gain de 73 %. Et surtout on évite a priori que les fichiers gonflent, gonflent, gonflent dans le futur, puisqu’à chaque nouvelle branches majeures de SPIP on ne listera plus les versions incompatibles des plugins.
Il faudra encore adapter SVP pour chercher automatiquement la bonne version.
Et puis il faut que je regarde pour voir si on ne pas garder une seul paquet par plugin, le dernier, vu que svp de toute facon va forcément chercher la dernire.
Et en ne mettant que le tout dernier tag dans les versions thin par branch de spip
On gagne 86 %, et surtout on limite drastiquement l’inflation.
On peut me confirmer qu’actuellement dans SVP on ne peut pas, en pratique, on ne peut mettre à jour / installer que la toute dernière version d’un plugin ?
Notes: mon implementation suppose qu’un dépot git ne correspond qu’à un préfix. Ce qui est normalement le cas, sauf exception (renommage de plugins / déplacement) mais ces exceptions me semble suffisament rares et voulues (on ne veut plus de l’ancien prefixe) pour qu’on puisse faire « comme si »)
Oui depuis les dépôts «distants» (issus de archives.xml), depuis la recherche de plugin donc, et non depuis les plugins locaux : tu peux activer un plugin d’un répertoire spécifique même si ce n’est pas sa version la plus haute ; cela dit il faut activer une config de SVP « Autoriser l’activation des paquets obsolètes ».
Et donc comme c’est ce qui nous intéresse en l’espèce, tout est bon 
On peut se permettre de filtrer ce qu’on envoie dans le archives.xml
Pour mémoire, outre que ce chargement de 9 Mo toutes les 6 heures m’agacait, voici aussi une des raisons :
Pour l’heure on a une MR dans le debardeur qui permet de generer chacune des versions.
Marcimat est en train de déployer cela sur contrib.spip.net / files.spip.net ; c’est un peu galère car il faut regenerer les json, et surtout cela pose problème pour les depots git qui ont été déplacés. Mais « on » (il en fait) va s’en sortir.
L’étape suivante sera de faire en sorte que SVP se branche, par défaut, sur les versions lights, avec possibilité de debrayer dans 2 cas au moins
Il reste les dépots de spip/x qui ont été déplacés à faire (breves, urls_etendues => urls, …) etc. Mais «on» a fait tous les autres de externals, spip-contrib-* …
Merci Mathieu
et vive tous les « On » qui font pour tous…
bisous de fin d’année
Et donc pour info ça génère ça sur Contrib actuellement, pour le dépôt principal
Générer les archives.xml du dépot spip-zone debardeur/depots/spip-zone/
- archives.xml (maj): 9.0MiB — 3600 archives
paquet.xml de "spip-contrib-extensions/basecss-f5930-basecss-v3.0.7.zip" a une erreur XML : Entity 'nbsp' not defined
- archives.full.xml (maj): 7.9MiB — 2995 archives
- archives.thin.xml (maj): 1.7MiB — 1084 archives
- archives.thin.spip_4_4.xml (maj): 1.2MiB — 722 archives
C’est dommage que ce ne soit pas l’occasion d’utiliser l’API REST qui est disponible sur Plugins SPIP et Contrib pour récupérer juste ce que de besoin (compatibilité spip) en JSON. Il suffirait ensuite de modifier la partie de mise à jour à partir du XML par une mise à jour presque immédiate en JSON.
Dans une première étape on pourrait garder les tables des plugins en local avant de migrer plus loin. Mais ça aurait fait une étape sympa sans être trop gourmande en code.
Pour mémoire j’ai mis à disposition cette API depuis plusieurs années et j’ai même créé un plugin SVP Référentiel qui ne crée la base que sur le serveur de plugins et donc allègerait tous les spip courants.
Enfin, je dis ça…
Oui, je suis d’accord qu’avec du temps et de l’énergie il faudrait aller là dessus, ou quelque chose d’équivalent, mais il faut aussi veiller à ce que cette API ne fasse pas tomber Contrib… Ce monde est pourri de bots en tous genres et particulièrement de bots d’aspirateurs IA très sots et infernaux qui pourrissent la vie, et donc il faut être vigilent avec tout ce qui est API ouverte, surtout avec de la recherche libre.
Mais déjà faire cette petite modification et changement nous prend beaucoup de temps (et ça ne nécessite pas ou quasi pas de toucher SVP), c’est encore autre chose de basculer sur du requêtage d’API, et ça ne concernerait que des SPIP futurs ; or les problèmes de ce XML grossissant sont déjà aussi pour tous les sites présents. Et j’étais déjà très réticent à mettre le nez dedans…
Par ailleurs il me semble, mais je me trompe peut être, que l’API de Contrib se base elle-même sur le dépôt XML, qui est déjà un problème à la base car grossissant indéfiniment actuellement… La gestion même du stockage des différents Zips de chaque version me questionne aussi (alors que les forge Git peuvent fournir des URLs de zip ou d’artéfact générées, ce dont se sert Composer notamment).
Cet ecosystème de zip / json a quelques lacunes aussi : on l’a vu encore avec Maieul ce matin, il conserve tous les zips de dépots qui ont été déplacés sous d’autres noms (et n’actualise plus leurs .json associés du coup).
Bref c’est pas si simple, et s’y retrouver n’est pas évident…
Maintenant cela dit, si tu as le temps de retrouver les liens des tickets / discussions qui parlaient de cette API, ça peut être cool pour retrouver les petits 
Je n’ai rien d’autres à ajouter à ce qu’à dit marcimat, que je remercie encore d’avoir pris à bras le corps ce chantier qu’il ne voulait pas prendre.
Oui c’est exact, je ne sais pas d’ailleurs contourner ça comment sauf à générer une sorte de clé propre à spip ?
Oui c’est normal, il faut bien une base quelque part mais il n’y a que le ou les serveurs qui s’en servent. On peut mettre autant de serveurs qu’on veut mais c’est exact qu’il n’existe pas aujourd’hui de mécanisme de balance pour les épuilibrer.
C’est à dire ? Quand on change les préfixes ou juste le nom des zips ? Oui là il me semble qu’il y a une persistence car on ne sait plus si le zip est lié à un plugin qui existe encore.
Oui c’est pas simple, j’ai jeté un oeil ce matin aussi. Mais ce n’était pas une critique comme semble le ressentir @maieul, surtout vu mon taux d’implication actuel. Juste une idée car il y a des chances que la solution prise ne soit pas pérenne.
Alors moi les tickets pour décrire du fonctionnel c’est pas ma tasse de thé. Je vais voir ce que j’ai en magasin au cas où