je propose donc qu’on fasse mercredi à 13h, ca à l’air de marcher pour un peu près tout le monde
1 « J'aime »
J’aimerais bien qu’on y traite aussi la fin du dépiautage de SVP en séparant la construction du référentiel des plugins de l’installation des plugins.
J’avais déjà commencé sur la base de la 4.1 et créé le plugin SVP Référentiel qui a vocation à gérer la bases des plugins (installée sur Contrib et/ou Plugins SPIP) et à fournir l’API REST pour y adresser des requêtes.
C’est donc pas mal avancé coté extraction maiscoté installation il faut définir le mécanisme qui remplace l’utilisation de la base SPIP.
Je trouve que SPIP 5 serait l’occasion de traiter enfin ce sujet surtout que l’arrivée de Composer devrait à terme influer sur l’installation mais pas le référentiel.
En soit je ne suis pas contre cela, mais il faut que des gens s’y mettent.
La 5.0 est prévue pour fin janvier 2025, c’est tout bientôt ! … il me semble illusoire de voir ce découpage arriver dans cette version, sachant qu’aucun chantier n’est actuellement engagé en ce sens dans le Core & SVP dans des PR.
J’aimerais bien qu’on puisse effectivement revoir le code & structure de SVP cela dit après… notamment pour déplacer une partie dans les lib Composer mieux testées. Mais ce n’est pas ma priorité là en tout cas, et en plus je sens que c’est pas quelque chose de si simple que cela ce chantier.
Je vois aussi que c’est bien complexe de gérer un système de dépendance, et que SVP est aussi en limite dans différents cas (et que son code aurait bien besoin d’être revu), et qu’on a toujours besoin de gérer de plus en plus de dépendances composer aussi pour les plugins, et que tout cela est plus ou moins incompatible qui plus est.
J’ai écouté distraitement une conf récente sur le youtube de l’AFUP sur WP et ses plugins, qui a les mêmes problématiques : du coup chaque plugin fournit son vendor avec toutes les librairies dedans préfixées du nom du plugin : ainsi si le plugin X dépend de psr/log, il va préfixer les namespace de X (dans vendor et dans son code). Ça résout un point : chaque plugin peut avoir la version N quelconque d’une lib, sans que ça conflicte avec un autre plugin qui utiliserait la même lib dans une autre version… mais d’un point de vue performance c’est plutôt très mauvais : tu te retrouves avec autant de fois vendor/psr/log que de plugins par exemple, et tous seront chargés : c’est lourd (tu dupliques tous les fichiers, tu dupliques les instances de toutes les classes concernées), vraiment peu efficace, mais ça répond à la problématique : pouvoir activer un plugin depuis l’interface de WP et que ça fonctionne.
On va se retrouver avec le même problème avec SVP et les plugins SPIP, à chaque fois qu’un plugin embarque un vendor/ , potentiellement il casse un autre plugin SPIP faisant pareil, parce que l’un et l’autre demandent des versions différentes de mêmes librairies.
Le panel est encore limité pour ce qui est des plugins communautaires.
Si tu regardes par exemple composer.lock · master · spip-contrib-extensions / optimages · GitLab tu vois qu’il ajoute psr/log en version 1.1.4.
Dans SPIP 5 on a actuellement la 3.0.2 je pense. Et c’est pas la faute de la librairie optimages (qui tolère toutes les versions 1, 2 ou 3)… mais pour créer ce vendor/, il a du en choisir une des versions compat avec le PHP du plugin je pense… Et ce genre de cas (qui amènera des bugs) est obligé d’arriver dès que tu as plusieurs vendor/ de fournis dans différents plugins, et que ce n’est pas le Composer racine qui agrège juste les libs aux versions qu’il faut !
Bref, la réponse à apporter à cette problématique là n’est vraiment pas évidente, et ça me questionne effectivement plus que le découpage de SVP là (mais ça sera bien de le faire aussi !).
1 « J'aime »
Ok.
Je pense que c’était mon dernier essai pour essayer de participer à spip malgré la tournure technologique qui laisse les non professionnels sur le bord de la route qui a pourtant été longue.
Je vous souhaite le meilleur pour l’avenir de spip que je suivrais gentiment au travers de mes plugins tant que je pourrais.
Serait-il possible d’être désabonné des équipes spip, je resterais attentif sur les sujets de plugins uniquement mais inutile de recevoir des notifications qui ne correspondent pas à mes attentes.
Après 18 ans ça fait bizarre.
1 « J'aime »
Je comprend cette réaction mais …
Actuellement, il y a un (petit) quarteron qui fait des trucs ésotériques sur les fondations de spip. Ces trucs n’ont rien à voir directement avec les motivations qui amènent à utiliser spip, à développer des sites avec SPIP, à créer des plugins ou même proposer des améliorations dans le core ou dans la dist.
Marcimat explique parfois des trucs qui ont du sens, mais partiellement (normal car il a bien d’autres choses à faire), et parfois certaines autres demandes d’aides à la comprenette sont rejetées.
C’est une situation nouvelle pour ceux qui suivaient les devs ou y participaient, de plus ou moins près, et qui ne suivent plus.
En plus, j’ai un peu des inquiétudes sur ce sur quoi ça va déboucher : je redoute la possibilité qu’une fois la composerisation atteinte, il n’y ait plus que le petit quarteron qui puisse participer, encore, comme pour ces devs de transition… Car dans ce cas, les bonnes raisons pour lesquelles ces devs auront été fait (librairies pas à maintenir, écosystème tout ça) ne suffiront pas pour que SPIP vive. Car Spip ok aura de nouveaux atouts et atours écosystèmiques, mais pour vivre, il faudra que spip soit encore (relativement) facile à comprendre et améliorable : « comme avant ».
Pour ma part, même avec ces inquiétudes, je fais quand même confiance sur le bienfondé à long terme…
Et alors donc ?
Historiquement, tous les devs spip comprenaient ou pouvaient comprendre ce que faisaient les autres devs spip. Il y avait un « noyau » SPIP. Ce n’est plus le cas, il y a un « sous-noyau » qui refait les fondations… et les autres sont plus ou moins hypnotisés par ces avalanches de logs qui tiennent l’avenir de SPIP entre leurs commits mais ne veulent plus rien dire (car les fondations sont sous terre et invisibles).
Ces « autres » ne doivent pas se laisser paralyser. Ils peuvent définir leurs propres projets sans rapport avec le travail sur les fondations. Ils peuvent développer des fonctionnalités pour les utilisateur⋅ices : des aménagements pratiques et réellement utiles à Mme et Mr 1comite, 6visiteur et 0minirezo (les Michus de SPIP).
Et les fils sur ces forums amènent régulièrement des idées de chantiers.
4 « J'aime »
Selon ta volonté, c’est fait.
Merci, j’ai reçu deux mails en provenance de Gitlab mais j’ai pas bien compris en quoi ça répondait à ma demande mais je te fais confiance.
Quelle célérité !
Et tu as le droit de changer d’avis
1 « J'aime »
heu oui : même pas le temps d’essayer d’argumenter pour te faire changer d’avis…
J’ai peut être répondu abruptement en disant que c’est compliqué pour la 5.0 : mais notre problématique était de stabiliser le code dont on a des travaux en cours pour sortir une béta, et elle n’est pas encore sortie parce qu’il faut revoir des outils de release et qu’il y avait d’autres corrections à faire finalement. Et tu viens nous rappeler : tiens si on ajoutait cela pour la 5.0, dont le chantier dans SVP n’est pas du tout esquissé encore, où il n’existe pas de PR. On n’est juste pas sur la même timeline là 
Rien n’empêche de se préparer la 5.1 plus tard avec ça
J’ai digressé sur un autre sujet des dépendances, qui me semble aussi assez proche car il peut concerner SVP et les plugins aussi… C’était probablement pas le moment.
Je suis désolé si tu ressens un virage technologique, ce qui est tout à fait vrai, mais qui n’est pas spécifique à SPIP non plus (s’exclure de l’écosystème PHP et son évolution & fonctionnement habituel, c’est aussi se tirer une balle dans le pied).
Je constate que je repousse ce découpage de SVP, pour les raisons que j’ai indiqué et parce que j’aspirais avoir auparavant un conteneur de services dans SPIP (ce qui n’est pas encore le cas en 5.0 par ailleurs à cette date), et que j’ai d’autres priorités sur mon temps libre : je peux juste dire dans ce cas il faut trouver d’autres personnes pour porter le sujet avec toi et faire les PR et tests en conséquence.
J’espère que tu continueras à faire avancer les sujets qui te portent, mais essaie de ne pas trop nous en vouloir si certains préfèrent consacrer leur temps disponible et énergie à d’autres problématiques que celles-ci. Et je dis cela en sachant que je n’ai rien produit de bien intéressant dans SPIP depuis plusieurs mois, à part de la maintenance et correction de bugs, pourtant totalement nécessaire aussi.
1 « J'aime »
J’ai commencé le chantier SVP il y a 3 ans avec SVP référentiel dans l’espoir justement de se débarrasser rapidement de la base pour mettre en place juste l’installation dans les sites de production, ce qui sera la réalité une fois composer complètement intégré. C’était à mon avis la bonne anticipation, aujourd’hui c’est un fardeau.
Non c’est intéressant mais ça ajoute à la distance qui nous sépare d’une implémentation d’un nouveau SVP.
On porte SVP tous les deux depuis des années, on y était pas loin à une époque, je doute que beaucoup s’intéresse encore à ce sujet.
Ce n’est pas le problème du tout.
Je dis juste que l’on ne peut pas toujours proposer des sujets à coté de la plaque sauf à être capable d’y travailler seul, ce qui n’est pas le cas (ni l’envie d’ailleurs).
Donc mieux vaut se rabougrir sur quelques petits sujets de plugins qui surement disparaitront un jour eux aussi par manque de temps, d’envie et de capacité à appréhender le nouvel écosystème.
Mais ce n’est pas grave, c’est juste le temps qui passe et la constatation qui va avec.
Hello,
Je vois passer encore des plugins uniquement SPIP 4 qui contiennent encore l’attribut categorie dans le paquet.xml.
Peut-on enfin supprimer totalement cet attribut en SPIP 5 de façon détecter et obliger la suppression de cet attribut ?
Je pense qu’il y a suffisamment de chance qu’on ne traine pas des plugins SPIP 3 en SPIP 5.
Merci d’avance.
- spip/ecrire & les plugins-dist/ ont encore cet attribut déjà.
- si on le supprime de la DTD, effectivement ça va vraiment planter un grand nombre de plugins de la zone. Soit à peu près tous les plugins en fait Sourcegraph
- donc il faudrait faire une passe automatique dans ce cas aussi sur la zone
Je n’ai peut être pas entièrement suivi, mais c’est quoi le problème avec ce categorie s’il reste présent ?
Notons que dans les composer.json il y a une entrée keywords (une liste) qui est libre. Ex: composer.json · main · spip-league / easy-coding-standard · GitLab
Dans la même veine, il y avait etat qui serait à enlever / ou rendre optionnel au profit de la version semver indiquée (-dev, -beta, -alpha, -rc …). Et si on rendait les attributs version et etat optionnels dans la balise paquet des fichiers paquet.xml ? & Évolution paquet.dtd (#9) · Tickets · spip / prive · GitLab
Ben il faut bien un jour nettoyer ce qui ne sert plus, surtout que c’est le cas depuis SPIP 4. Les gens pensent mettre une catégorie (dont la liste est aussi fausse) alors que la catégorie est affectée de façon externe via Contrib ou Plugins SPIP.
Je reviendrais sur ce sujet d’ailleurs dans un autre fil.
En plus, à partir du moment où un plugin a une branche SPIP 4 et plus ça ne pose aucun problème, donc je ne vois pas en quoi les plugins-dist serait concernés.
Pour l’état oui c’est bien aussi mais ça demande à revoir SVP aussi et que si on avait coupé en deux ça serait plus simple.
D’ailleurs je suppose qu’un jour le composer.json sera aussi à lire pour constituer les informations du plugin.
Je pense que @JamesRezo est à même de nous faire un script pour faire ce ménage en masse (call him mister propre ^^)
@marcimat j’ai peut-être une idée de compromis pour SVP.
Là tu vois j’ai besoin de modifier certains affichages des pages plugins privées qui ne servent que pour Contrib ou Plugins SPIP. C’est embêtant car je dois modifier une plugin-dist pour cela alors que c’est uniquement lié à la gestion de sites de la Galaxie.
Je proposerais bien qu’à minima on transfère les affichages du privé (et surement des items de langues) dans le plugin SVP Référentiel qui serait pour l’instant dans une version préliminaire en attendant de récupérer la base elle-même. Le seule souci c’est qu’il faudrait que je fasse une version v0 de ce plugin qui a une version 1 plus complète mais ça ne doit pas être rédhibitoire.
Qu’en penses-tu ?
Ah oui et question subsidiaire : pense-t-on passer Contrib et Plugins SPIP sous spip 5 à sa sortie ou pas, sinon ça veut dire qu’il faudrait faire ce découpage sur spip 4
Ah, les techniques « de hussard » et « la shlague », tu veux dire ? pour qu’on nous traite de nazis une fois de plus ? pas chaud …
Alors oui, effectivement, en général on fait cela… mais il y aura quelques plugins à vérifier quand même un peu.
Je suppose néanmoins que tu peux surcharger dans svp-referentiel les fichiers de svp en attendant qui sont concernés ?
Il conviendrait d’ouvrir ou réouvrir un sujet dédié car on digresse du code freeze pas mal là.
Le contexte est différent.
Je pense qu’au contraire ce serait bien vu.