- [spip-dev] Refonte Contrib - SVP et les catégories/tags (2019)
- [spip-dev] Catégorie de plugins, SVP, SPIP et Composer ? (2019)
Je suis certain que y avait d’autres discussions, mais je retrouve pas facilement
Y a aussi le plugin SVP Référentiel qui ne fait que créer la base des plugins dans un spip serveur et l’expose via le plugin SVP API.
Sur gitlab, si tu déplaces un dépot, par exemple spip/urls_etendues en spip/urls (pour matcher le prefixe du plugin), ou spip/breves en spip-contrib-extensions/breves, Gitlab gère très bien les redirections. Mais le débardeur n’a pas connaissance du déplacement actuellement (il lui manque peut être un hook pour gérer cela), et donc il conserve les données de spip/breves (qu’il devrait supprimer) et ajoute celles de spip-contrib-extensions/breves en plus (ça c’est bien).
Le problème qu’on a eu hier, c’est que à ces Zips sont associés un .JSON de description qui est généré par le débardeur, et on a fait régénérer tous les JSON pour ajouter un champ dedans. Cependant, il n’a modifié que les projets actifs, pas ceux qu’ils ne connaît plus (spip/breves par exemple), et quand le débardeur compile le fichier archives.xml, il va chercher TOUS les zips (pas que sur les projets « connus »), et tous leurs JSON (et sur certains donc, il leur manque le nouveau champ). Ces zips / json là sont périmés, à supprimer (du coup j’en ai fait une partie à la main, mais il en reste à faire)
Je pense qu’on en a bien conscience (en tout cas pour ma part).
Mais on fait ce qu’on peut !
non non je ne l’ai pas pris comme une critique.
Je n’arrive pas à retrouver des discussions sur le sujet pourtant je suis sur qu’il y en a eu. En général, j’écris mais là 
Hello,
@marcimat : on avait discuté et échangé sur le sujet du changement de la base des plugins vers un autre lieu de stockage. Tu n’aurais pas une trace de tout ça ?
Je sais aussi que j’avais fait un post quelque part sur comment découper SVP et où j’en étais.
En fait, pas mal de choses ont été faites :
- la typologie est sortie de SVP dans le plugin SVP Typologie qui est utilisé sur les serveurs
- les besoins de Plugins SPIP ont été exportés aussi
- SVP Référentiel existe pour créer une base de plugins
- SVP API existe et est prête si ce n’est les remarques que tu as fait
- et j’avais commencé en 4.1 à dépiauter SVP du référentiel des plugins pour n’y laisser que l’installation (pas fini car on se posait des questions sur le stockage)
Donc on a déjà pas mal avancé.
Indépendamment de la refonte globale du mecanisme, et de la production de depot plus leger, cedric a envoyé une MR pour optimiser le parging du xml
Optimisation de la gestion mémoire lors du phrasage des dépots (!4931) · Requêtes de fusion · spip / svp · GitLab pour les gens qui pourraient/voudraient relire et (in)valider
Deux points
- les dernières versions
.thinétaient vraiment très thin. C’est parce que j’avais dit de ne garder que le dernier tag. Mais en fait, le seul cas où l’on pourrait utiliser ce fichiers, c’est lorsqu’on a la constante de compatibilité forcée. Et dans ce cas il faut tout avoir… sinon on s’en sort pas j’ai corrigé - et du coup j’ai mis une MR sur svp pour chercher les fichiers les plus legers en priorité, en tenant compte de la config perf: lorsqu'on actualiser les dépôts distant, utiliser les variantes des dépôts d'archives par branches spip, ou à défaut thin, si disponibles (!4932) · Requêtes de fusion · spip / svp · GitLab p
Je ferme ce fil pour en ouvrir un de synthse de l’état actuel de ce qui existe comme amélioration effective
on peut aussi si on le veut rouvrir un fil pour les améliorations possibels dans le futur.
Merci pour tout ça.