[spip-dev] Catégorie de plugins, SVP, SPIP et Composer

Dev
1

Hello,

Aujourd’hui nous avons plusieurs chantiers en cours qui concernent les plugins :

  • SPIP et composer
  • Contrib, Plugins SPIP et la liste des catégories de plugins.

Le passage sous Composer va à plus ou moins long terme remettre en cause SVP.
SVP supporte plusieurs fonctions dont :
1- la “gestion” des catégories
2- la gestion des branches SPIP
3- la construction du référentiel des plugins et des dépôts.
4- l’installation des plugins incluant la gestion des dépendances.

La mise en place de Composer (objectif final avec les plugins) remet en cause complètement la fonction 4-. Par contre, et c’est un point que j’ai plusieurs fois remonté lors des discussions sur Composer, il nous faudra toujours assurer les fonctions 1 à 3 ne serait-ce que pour motoriser les sites de documentation des plugins.
En outre, la refonte de Contrib/Plugins SPIP remet en cause la liste actuelle des catégories pour en proposer une nouvelle plus aboutie et prenant en compte 10 ans d’évolution. Il va donc falloir modifier SVP pour en tenir compte et ce bien avant l’introduction du tout Composer.

C’est pourquoi je me disais qu’on pourrait aujourd’hui extraire les fonctions 1 à 3 de SVP pour ne laisser que la fonction 4, et ce dans la version SPIP 3.3.
Mon idée serait :

  • transférer les fonctions 1 et 2 dans SPIP directement. Cela correspond principalement à des globales, une balise pour les catégories et des filtres.
  • transférer la fonction 3 dans un plugin “Référentiel des plugins” qui construit la base des plugins à partir des archives XML. En complément, il serait bien de réfléchir à une autre manière d’intégrer dans le référentiel les plugins Github de façon corriger les liens erronés.
  • réduire SVP à la fonction 4 en nécessitant le plugin “Référentiel des plugins” pour un certain temps.

Qu’en pensez-vous ?

2

Là, comme ca, ca me parait une bonne idée, mais sans doute des imprévus que je prévois pas.

Le point qui me taquine un peu c'est que le passage à un système de catégorie SOUPLE (au sens de non fixé en dur, mais dépendant du referentiel de plugin) implique nécessairement une mise à jour de svp pour tout les sites actuelles s'ils voudront utiliser les plugins recatégorisé.

3

Yop,

Là, comme ca, ca me parait une bonne idée, mais sans doute des imprévus
que je prévois pas.

Oui y en a surement, il faut creuser un peu plus le sujet mais finalement les catégories sont très peu utilisées en dehors de Plugins SPIP.

Le point qui me taquine un peu c’est que le passage à un système de
catégorie SOUPLE (au sens de non fixé en dur, mais dépendant du
referentiel de plugin) implique nécessairement une mise à jour de svp
pour tout les sites actuelles s’ils voudront utiliser les plugins
recatégorisé.

Ah non je n’ai pas envisagé ça.
Je veux juste remplacer la liste actuelle par la nouvelle en préparation.
Mais c’est sur qu’il y aura une grande migration une journée.

4

ah. Ah mon sens ce serait mieux de séparer. Dire dans SVP "on a deux
niveaux de catégories". Et gérer la vérif de la cohérence dans le
réferentiel de plugin/contrib (puisque c'est le seul lieu où c'est
utile). Comme ca si dans 3 ans on se dit "il faut absolument créer une
nouvelle sous catégorie", bah on a juste à actualiser les infos dans le
referentiel/dans les paquet.xml, mais pas dans svp. On donc la grande
migration, on l'a fait qu'une fois.

5

Oups,

ah. Ah mon sens ce serait mieux de séparer. Dire dans SVP « on a deux
niveaux de catégories ». Et gérer la vérif de la cohérence dans le
réferentiel de plugin/contrib (puisque c’est le seul lieu où c’est
utile). Comme ca si dans 3 ans on se dit « il faut absolument créer une
nouvelle sous catégorie », bah on a juste à actualiser les infos dans le
referentiel/dans les paquet.xml, mais pas dans svp. On donc la grande
migration, on l’a fait qu’une fois.

Je ne suis pas sur de te suivre.
Ce que je propose :

  • sortir tout ce qui est catégorie et branche spip de SVP pour le mettre dans SPIP directement comme la partie gestion des plugins.
  • de sortir de SVP tout ce qui est lecture des XML et construction de la base plugins/paquets pour le mettre dans un plugin « Référentiel des plugins »
  • et donc de ne laisser dans SVP que le chargement des plugins et la gestion des dépendances qui un jour sera assurée par un nouveau mécanisme basé sur Composer.

Donc le fait que les catégories soient modifiées une fois ou n fois n’est pas mon objectif pour l’instant.
Tu vois le truc ?

6

Je ne suis pas sur de te suivre.
Ce que je propose :
- sortir tout ce qui est catégorie et branche spip de SVP pour le
mettre dans SPIP directement comme la partie gestion des plugins.
- de sortir de SVP tout ce qui est lecture des XML et construction de
la base plugins/paquets pour le mettre dans un plugin "Référentiel des
plugins"
- et donc de ne laisser dans SVP que le chargement des plugins et la
gestion des dépendances qui un jour sera assurée par un nouveau
mécanisme basé sur Composer.

Donc le fait que les catégories soient modifiées une fois ou n fois
n'est pas mon objectif pour l'instant.
Tu vois le truc ?

++
Eric

oui je vois le truc. La question est dans le point 1 (mettre catégorie
et branche dans SPIP). Est-ce que SPIP a vraiment besoin de gérer les
catégories? Et si oui, est-ce que cela doit être "en dur". Pour moi
c'est uniquement le referentiel de plugin qui besoin de gérer la
catégorie, pas SPIP.

7

Yo,

oui je vois le truc. La question est dans le point 1 (mettre catégorie
et branche dans SPIP). Est-ce que SPIP a vraiment besoin de gérer les
catégories? Et si oui, est-ce que cela doit être « en dur ». Pour moi
c’est uniquement le referentiel de plugin qui besoin de gérer la
catégorie, pas SPIP.

Ah oui pigé.
C’est une bonne remarque oui.
Si on considère que c’est de la « gestion de plugins » au sens de l’API portée par SPIP, c’est du SPIP.
Si on considère que c’est du « Référentiel uniquement » alors oui on peut éviter de le mettre dans SPIP.

Un point important c’est la validation du paquet.xml.
Si on considère que la nouvelle DTD vérifie la liste des catégories (comme actuellement) alors oui il faut mettre les catégories dans SPIP.
Si on abandonne cette vérification car il y a trop de catégories ou qu’on veut être plus souple, alors on peut tout mettre dans le Référentiel oui.

Il y a peut-être d’autres critères pour choisir ?

8

SPIP en a besoin dans la gestion des plugins, si on veut laisser la
souplesse de faire une interface plus ou moins complète.

Quand on a 50 plugins activés par exemple, ça peut être bien de les
afficher par catégorie (au moins de premier niveau). Enfin c'est un
exemple, je veux dire, les catégories c'est pas forcément que pour la
"recherche" (trouver une fonctionnalité), mais aussi dans les trucs
existants sur un site installé quoi.

Et par contre ça doit pouvoir être souple (pipeline). Si on parle vision
à long terme avec Composer, ça veut dire possibilité d'avoir des
Distributions variées. Or là ce sont les catégories de la distribution
officielle. Mais si j'en fais une autre, je peux avoir besoin de
rajouter une catégorie qui n'est pas géré par la communauté, et que ce
soit visible dans l'interface.

9

Si c'est figé en dur dans SPIP, ça veut dire que si on veut modifier quelque chose là dedans il faut sortir une release de SPIP et espérer que les gens mettent à jour.
Ça me parait un peu trop figé, non ?
(ou c'est moi qui n'ai pas pigé)

10

Pour ma part, je regrette SPIP 2.1 (ou 2) où l’arborescence des plugins était celle sur le disque dur du serveur.
Parce que ça permettait d’avoir son propre classement au lieu d’un classement imposé (qu’en ce qui me concerne, je n’ai jamais utilisé).

11

Hello,

SPIP en a besoin dans la gestion des plugins, si on veut laisser la
souplesse de faire une interface plus ou moins complète.

Quand on a 50 plugins activés par exemple, ça peut être bien de les
afficher par catégorie (au moins de premier niveau). Enfin c’est un
exemple, je veux dire, les catégories c’est pas forcément que pour la
« recherche » (trouver une fonctionnalité), mais aussi dans les trucs
existants sur un site installé quoi.

Je suis d’accord.
C’est une « fonctionnalité » de base des plugins et c’est dans les paquet.xml.
J’aurais tendance à inclure ça dans SPIP.

Et par contre ça doit pouvoir être souple (pipeline). Si on parle vision
à long terme avec Composer, ça veut dire possibilité d’avoir des
Distributions variées. Or là ce sont les catégories de la distribution
officielle. Mais si j’en fais une autre, je peux avoir besoin de
rajouter une catégorie qui n’est pas géré par la communauté, et que ce
soit visible dans l’interface.

Pourquoi pas mais je reste un peu circonspect sur le besoin.
Si il « manque » une catégorie autant la rajouter, au moins à terme, plutôt que de laisser ça à un plugin qu’il faudra nécessiter pour l’utiliser.
Je pense qu’il vaut mieux réfléchir à une logique « simple » d’évolution.

12

Yop,

13

Humm,

14

Eric Lupinacci a écrit le 17/05/2019 à 08:58 :

Humm,

Le jeu. 16 mai 2019 à 21:32, RealET <real3t@gmail.com <mailto:real3t@gmail.com>> a écrit :

    Pour ma part, je regrette SPIP 2.1 (ou 2) où l'arborescence des plugins
    était celle sur le disque dur du serveur.
    Parce que ça permettait d'avoir son propre classement au lieu d'un
    classement imposé (qu'en ce qui me concerne, je n'ai jamais utilisé).

Merci beaucoup pour ton mail qui nous éclaire et fait avancer le débat.

C'est juste un témoignage utilisateur.

Je ne vois pas le rapport entre les catégories de plugin et les répertoires de rangement des plugins dans une installation SPIP.
Et ce n'est pas les catégories de plugin qui ont mis à la benne l'affichage dont tu parles.

De ce point de vue, tu as tout à fait raison.
Ça n'est pas ces catégories qui ont imposées ce changement d'interface.

Mais s'il n'y a pas corrélation, il y a eu concomitance.

Et ça me semble pertinent de rappeler cette perte maintenant, au moment où l'on parle de changements qui pourraient concerner SVP et l'affichage des plugins.

15

Eric Lupinacci a écrit le 17/05/2019 à 08:49 :

Yop,

Le jeu. 16 mai 2019 à 21:30, nicod_ <nicod@lerebooteux.fr <mailto:nicod@lerebooteux.fr>> a écrit :

     > - transférer les fonctions 1 et 2 dans SPIP directement. Cela
    correspond
     > principalement à des globales, une balise pour les catégories et des
     > filtres.

    Si c'est figé en dur dans SPIP, ça veut dire que si on veut modifier
    quelque chose là dedans il faut sortir une release de SPIP et espérer
    que les gens mettent à jour.
    Ça me parait un peu trop figé, non ?
    (ou c'est moi qui n'ai pas pigé)

C'est déjà le cas aujourd'hui dans SVP.
Mais je ne suis pas sur que le but soit de modifier cette liste tous les mois.
On a tenu 10 ans avec la première liste...

Il me semble que là n'est pas la question.

La question, c'est : comment vont réagir les versions de SPIP non mises à jour avec ce changement de catégories ?
- ça ne va plus marcher ?
- ça ne verra que les plugins d'une catégorie commune ?

16

Hello,

C’est déjà le cas aujourd’hui dans SVP.
Mais je ne suis pas sur que le but soit de modifier cette liste tous les
mois.
On a tenu 10 ans avec la première liste…
Il me semble que là n’est pas la question.

Ben si c’était la question sur l’évolution des catégories dans le temps.

La question, c’est : comment vont réagir les versions de SPIP non mises
à jour avec ce changement de catégories ?

  • ça ne va plus marcher ?
  • ça ne verra que les plugins d’une catégorie commune ?

Mais de quoi tu parles ?
Qu’est ce qui ne va plus ou pas marcher ?
Quelles sont les version de SPIP qui utilisent les catégories?

Avant d’agiter le chiffon rouge de la mort qui tue ça serait bien d’identifier précisément les problèmes.
Il y en aura surement mais je ne suis pas sur que cela sera insurmontable et de toute façon rien n’interdit d’y réfléchir !

Les catégories sont d’abord utilisées sur le site Plugins SPIP pour ranger les plugins.
Les API sur les catégories sont toutes dans SVP.
SVP est apparu avec SPIP 3 et les paquet.xml.
SVP propose une recherche avec le critère catégorie.
J’ai l’impression qu’au pire on peu désactiver ce critère pour éviter tout effet de bord d’un changement de catégorie et ce pour la version 3.0 qui ne sera plus maintenue.

C’est une analyse rapide à compléter.

17

autre piste : est-ce que la liste de catégories ne pourrait pas être servi à SPIP par un serveur externe (genre : le référentiel de plugin). Comme cela en cas de changement de liste, l'actualisation se fait plus simplement.

18

Eric Lupinacci a écrit le 17/05/2019 à 10:16 :

Hello,

Le ven. 17 mai 2019 à 09:50, RealET <real3t@gmail.com <mailto:real3t@gmail.com>> a écrit :

     > C'est déjà le cas aujourd'hui dans SVP.
     > Mais je ne suis pas sur que le but soit de modifier cette liste
    tous les
     > mois.
     > On a tenu 10 ans avec la première liste...
    Il me semble que là n'est pas la question.

Ben si c'était la question sur l'évolution des catégories dans le temps.

Je parlais de la question de nicod

    La question, c'est : comment vont réagir les versions de SPIP non mises
    à jour avec ce changement de catégories ?
    - ça ne va plus marcher ?
    - ça ne verra que les plugins d'une catégorie commune ?

Mais de quoi tu parles ?

/ecrire/?exec=charger_plugin

Qu'est ce qui ne va plus ou pas marcher ?

La recherche des plugins : la liste des catégories est une liste déroulante.
Si je laisse par défaut "Toutes les catégories", est-ce que les plugins trouvés sont aussi ceux d'une catégorie non présente dans la liste (pas de problème si la liste change) ou seulement dans la liste (et dans ce cas, impossible de trouver et installer un plugin en dehors).

Quelles sont les version de SPIP qui utilisent les catégories?

La, je viens de regarder /ecrire/?exec=charger_plugin en 3.2.4

Avant d'agiter le chiffon rouge de la mort qui tue ça serait bien d'identifier précisément les problèmes.
Il y en aura surement mais je ne suis pas sur que cela sera insurmontable et de toute façon rien n'interdit d'y réfléchir !

C'est exactement ce que je fais.

Et comme c'est toi qui a codé SVP, je suppose que tu as les réponses à mes questions.

Les catégories sont d'abord utilisées sur le site Plugins SPIP pour ranger les plugins.
Les API sur les catégories sont toutes dans SVP.
SVP est apparu avec SPIP 3 et les paquet.xml.
SVP propose une recherche avec le critère catégorie.
J'ai l'impression qu'au pire on peu désactiver ce critère pour éviter tout effet de bord d'un changement de catégorie et ce pour la version 3.0 qui ne sera plus maintenue.

D'où la question de Nicod : "si on veut modifier quelque chose là dedans il faut sortir une release de SPIP et espérer que les gens mettent à jour."

19

Yop,

20

Pffffffffff,

On a tenu 10 ans avec la première liste…
Il me semble que là n’est pas la question.

Ben si c’était la question sur l’évolution des catégories dans le temps.
Je parlais de la question de nicod

Ben oui moi aussi et j’ai répondu.

Mais de quoi tu parles ?
/ecrire/?exec=charger_plugin

Oui ça j’ai compris…

Qu’est ce qui ne va plus ou pas marcher ?
La recherche des plugins : la liste des catégories est une liste déroulante.
Si je laisse par défaut « Toutes les catégories », est-ce que les plugins
trouvés sont aussi ceux d’une catégorie non présente dans la liste (pas
de problème si la liste change) ou seulement dans la liste (et dans ce
cas, impossible de trouver et installer un plugin en dehors).

Si on enlève le critère on enlève le critère.
Je sais pas trop comment le dire autrement.

Quelles sont les version de SPIP qui utilisent les catégories?
La, je viens de regarder /ecrire/?exec=charger_plugin en 3.2.4

J’ai donné la réponse : SPIP 3.

Avant d’agiter le chiffon rouge de la mort qui tue ça serait bien
d’identifier précisément les problèmes.
Il y en aura surement mais je ne suis pas sur que cela sera
insurmontable et de toute façon rien n’interdit d’y réfléchir !
C’est exactement ce que je fais.

Excellent !

Et comme c’est toi qui a codé SVP, je suppose que tu as les réponses à
mes questions.

Je t’ai donné ce que j’avais en tête sans regarder plus profondément.
Maintenant, je ne pense pas que depuis le premier message de ce fil on ait avancé d’un iota sur cette proposition de découpage e SVP…
Je suis étonné que les tenants de Composer n’ait pas plus d’avis sur le sujet car je pensais que ça pourrait faciliter le travail futur mais je dois me tromper.