Quelques détails ici : https://www.youtube.com/watch?v=VGPBn0-xvp8
Et une liste des nouveautés à lire ici Symfony 7.2 curated new features (Symfony Blog)
Il y avait eu une conférence à l’Afup également
Je crois comprendre, en lisant entre les lignes ici et là, qu’au delà de la composerisation, il y a une volonté de transformer SPIP en une application Symfony.
Je me fourvoie ?
D’utiliser plus d’éléments de SF oui très certainement, et possiblement oui le kernel / micro framework.
Dans tous les cas, il n’est pas possible en l’état de SPIP d’utiliser la structure de Symfony ; notamment le http-kernel, trop de globales dans le code, impossible de mettre le vhost de SPIP dans une répertoire public/ , avec le reste des fichiers en dehors…
Mais en vrai @nicod_ je ne sais pas comment faire, ou comment tu compterais faire, ou d’autres de la commu différemment ?
- le code de SPIP en l’état est difficilement maintenable, testable, et est spaghetti et très vieilli : au fil des versions PHP qui sortent, et l’évolution du web, des libs PHP en Composer, je ne vois pas comment on peut suivre en l’état.
- même le code des squelettes est pour moi peu clair, et difficile à déboguer (les erreurs indiquées n’indiquent pas forcément exactement l’endroit du problème) : pour peu que tu aies fait un peu de Twig par exemple, avec coloration syntaxique correcte dans ton IDE, et gestion d’erreur très précise lorsqu’il y en a, c’est déjà un autre monde (indépendamment de la gestion des boucles évidemment). Et tente de comprendre en ouvrant debusquer.php, je te souhaite bon courage
Bref, une personne, James au moins, essaie d’avancer pour transformer le code de SPIP pour qu’il permette d’être mieux testable, de se libérer une partie de la maintenance de notre code en s’appuyant sur des libs (symfony notamment) maintenues (et qui sont à jour de protocoles web, et bridges, que ne sait pas traiter SPIP) … Et je suis bien d’accord avec ça, alors je soutiens comme je peux.
Le simple fait d’avoir une RequestInterface et une ResponseInterface dans SPIP serait le b.a.-ba ( PSR-7). Il doit plus y avoir beaucoup d’applications qui n’utilisent pas cela encore maintenant…
Et je sais que c’est compliqué pour beaucoup de personne : et beaucoup ne voient pas que le code de SPIP actuel est loin d’être si simple et évident : il ne paraît pas compliqué par habitude d’usage surtout ; Et pas pratique pour les devs non plus : si tu surcharges machin_dist() en machin() : ton IDE ne le sais pas, ne le comprends pas… il ne peut pas t’aider ensuite, contrairement à si tu fais la même chose en étendant une classe PHP, où il pourra faire de l’analyse statique, t’indiquer les trucs dépréciés dans la classe parente éventuellement. Il ne comprends pas non plus si tu fais include_spip('inc/qqc'); contrairement à si tu fais use Namespace\Truc, tout en étant plus performant en PHP. C’est plein de petits détails comme ça aussi.
Bref, je ne sais pas trop quoi dire : j’ai un peu lâché l’affaire aussi de toutes façons depuis quelques mois ; (se faire traiter de n**i sur l’IRC récemment aussi par qq·n connu dans la commu n’a pas du tout plu à tout le monde, par exemple, disons le… alors la charte tout ça… )
Heureusement, il y a de nouvelles personnes qui arrivent dans l’équipe de maintenance et apportent une grande aide sur les PR, les reports, les releases, et ça fait un bien fou. Merci à Maieul notamment dernièrement d’avoir pu gérer cela.
Cela dit également, je trouve que la façon qu’explique Nicolas Grekas sur les releases de Symfony en début de la vidéo est bonne. Releaser à une date définie, quelque soit ce qu’il y a dedans, et avoir des cycles de vie de l’application bien identifiés à la base du coup. Ça permet à la fois d’avancer, tout en gardant des versions LTS.
Et vraiment je crois qu’on peut se féliciter des releases mensuelles de ce point de vue. Même si c’est un temps non négligeable à y passer. Alors encore merci à celles & ceux qui y participent de différents moyen.
Merci marcimat pour cette réponse.
J’ajouterai une chose : le but n’a jamais été de transformer SPIP en application symfony.
Que certains élèments soient pris chez symfony ou ailleurs, oui. Mais c’est posé, réflechi à chaque fois, selon le composant concerné et la maintenabilité interne (pour SPIP) et externe (y-a-til des gens qui maintiennet le composant) ? Voir à ce sujet la discussion en anglais d’il y a peine 3 mois Des nouvelles de Wordpress - #6 par rastapopoulos
Et je risque de me repeter, mais si on pouvait éviter de faire des procès d’intention quand les gens disent et reptent « ce n’est pas notre but », ce serait agréable.
Parceque ces procès d’intention usent moralement et psychniquement à la longue les personnes à qui ces procès sont faits. Et ces personnes sont aussi celles qui tentent, une grande partie d’entre elles bénévolement (elles n’ont pas de client·e, un métier qui ne dépend pas de SPIP) de maintenir cet outil en le rendant compatible avec les différentes evolutions du web.
Pour ne prendre que mon exemple : depuis que j’ai accepté d’etre dans la team maintenance pour soulager marcimat, bruno, james, cerdic (vous vous rendez compte : 4 personnes qui bossaient EFFECTIVEMENT sur l’outil utilisé par 6000 sites), je me prend en permanence des remarques sur « vous voulez allez trop vite » « vous allez vers autres choses que du SPIP ». Alors qu’à chaque fois
- On explique le pourquoi et le comment
- On documente au max qu’on peut les changements, les implications
Parce qu’on sait que c’est pas facile. On sait que les gens ont du mal à suivre (comme j’ai du mal à suivre personnellement les évolutions des css par ex, mais je ne passe pas mon temps à dire dès qu’il y a une proposition de gérer autrement les css que ca va trop vite). Et donc on essaie de trouver un juste milieur entre évolué (pour ne pas s’user à reinventer la roue à chaque fois) et garder les fonctionnalités publiques telle qu’elles (pour ne pas casser les habitudes des unes et des autres) tout en documentant.
Alors se voir reprocher quasiment toutes les semaines d’avoir un agenda caché, ou encore de ne pas tenir compte des besoins des gens alors que précisément on contribue bénévolement à un outil qui ne nous est pas forcément indispensable, bah ca use. Vraiment. Beaucoup. Surtout quand on repete x fois que non ce n’est pas l’intention.
Alors les ami·es qui utilisent SPIP à usage pro et intensif. Que vous soyez perdu·es, deboussolé, etc je le comprend volontier. Que vous ayez besoin d’aide aussi. Et d’ailleurs ce n’est pas pour rien que j’ai proposé cette année 6 seances de formations (par contre pour ma part j’attend toujours les formations proposés/promises sur des sujets que je ne maitrise pas…). Mais s’il vous plait, arretez de faire en permanence des procès d’intention.
Ou alors un jour marcimat, james, bruno, placido, bricebou et moi meme on arretera de faire des releases usés par ces discours. Et faudra pas pleurer si votre SPIP ne pourra plus s’installer un jour chez votre hébergeur web favori.
D’autant plus que PAR ailleurs il y a plein de domaine autre que du pur PHP dans SPIP qui nécessitent des compétences que vous avez. Par exemple j’ai vu passé pas plus tard que ce matin une réflexion sur les composants web. Je ne sais pas personnelement ce que c’est. Mais je pense que si les gens qui sont compétents dans ce domaine disent « à ce serait une piste à creuser/faire » et bah je leur fais confiance. Je serai un peu perdu à certains moments, mais j’irais pas dire « surtout ne faite pas ca » ou bien « votre projet c’est en fait de faire cela » alors que les personnes ne disent pas ca.
Spip c’est un beau projet qui permet à des gens d’apprendre du web. Mais c’est un projet complexe, parce qu’il melent des gens aux compétences et aux attentes différentes. C’est ce qui le rend à la fois faible et puissant. Essayons d’en garder le meilleur (la diversité des profils) et d’en chasser le pire (la peur face à ce que l’autre fait).
Alors la réponse ne me semble pas si tranchée que cela je crois… enfin ça dépend ce que tu entends pas «application symfony» aussi. Le symfony/framework-bundle n’est pas si gros de base (ce n’est pas symfony/symfony). Donc il serait possible d’utiliser leur framework, et de faire un bundle SPIP dedans qui fait le café aussi.
Alors la réponse ne me semble pas si tranchée que cela je crois… enfin ça dépend ce que tu entends pas «application symfony» aussi. Le symfony/framework-bundle n’est pas si gros de base (ce n’est pas symfony/symfony). Donc il serait possible d’utiliser leur framework, et de faire un bundle SPIP dedans qui fait le café aussi.
peut 'etre, mais ce ne serait pas un but, mais un moyen. Et ca change tout.
Merci pour les éclaircissements.
C’était un peu le but de ma question :
Car ce n’était pas une critique pleine de sous entendus mais une question.
Peut être mal tournée, et comme j’ai émis plusieurs fois des sous entendus pas très judicieux, je le reconnais, ça a peut être été mal reçu.
Mais oui, vous avancez vite, ça bouscule pas mal de choses, donc ça génère des interrogations car on ne voit pas le tableau fini.
Je ne vais pas jusqu’à demander que chaque choix de nouvelle implémentation soit validé par la communauté, ça prendrait des mois et ça finirait par tout arrêter.
Mais avoir des interrogations / des inquiétudes, quand on ne sait pas trop où on est et où on va, ça me parait légitime non ?
Est ce qu’il y a un état des lieux / une roadmap, mise à jour au fur et à mesure, qui indique par exemple quelle portion de code legacy de SPIP serait remplacé par quel composant Symfony ou autre ? Quelles pratiques habituelles propres à SPIP seraient modifiées, abandonnées ?
Bref, à quoi il faut s’attendre pour les contributions à SPIP (core et plugins) à l’avenir ?
Parfois aussi, entre deux phrases, je lis quelque chose comme ça :
et ce n’est pas la première fois que je vois des appels du pied à Twig.
C’est juste un exemple, mais voilà le genre de choses qui peuvent m’inquiéter si je n’ai pas de visibilité.
(et au passage, sur cet exemple là, pour le coup, ce serait catastrophique de décider sans la communauté)
Merci pour ces précisions, et désolé d’avoir été un peu grognon aussi (cela étant je pense que le fond de mon message reste important sur la vigilance dans la manière de parler de ce que fait l’équipe de maintenance).
Pour revenir donc à tes questions
Mais avoir des interrogations / des inquiétudes, quand on ne sait pas trop où on est et où on va, ça me parait légitime non ?
oui bien sûr, et on essaie d’expliciter
Est ce qu’il y a un état des lieux / une roadmap, mise à jour au fur et à mesure, qui indique par exemple quelle portion de code legacy de SPIP serait remplacé par quel composant Symfony ou autre ?
il me semble que James/MArcimat publient à chaque fois qu’il y une modification sur un composant, en disant quels sont les parties repris d’un composant autre ou pas. Par contre c’est vrai qu’il n’y a pas forcément une vue d’ensemble pour chaque element. Tout simplement je pense parce que le code de SPIP étant très très intriqués/spaghettis, il est difficile de l’avoir. Si tu veux l’enjeu dans ce travail — tel que je le percois sans m’y être penché concrètement — c’est de demeler les fils et une fois qu’un fil a été demelé, de se demander si on le garde tel quel où si on prend autre choses. Et ca rend compliqué du coup de dire « ces fils là vont changer pour tel équivalent » car la liste des fils n’est pas clair.
Quelles pratiques habituelles propres à SPIP seraient modifiées, abandonnées ?
pour le coup c’est le but du fichier UPGRADE_XX d’indiquer cela
et ce n’est pas la première fois que je vois des appels du pied à Twig.
Je crois qu’il faut vraiment percevoir la phrase de marcimat comme une explication des limites du système de squelette actuellement en terme d’implémentation technique. Mais pas en terme d’interface, car pour le coup je pense qu’il y a vraiment consensus sur le fait que le squelettage de SPIP est ce qui en fait sa spécificité, et passer à autres choses n’aurait plus de sens en terme de « ce qu’est SPIP comme projet ».
Ce n’est pas une nouvelle discussion que nous avons encore dans ce fil. Et il ne me semble pas que l’on ait émis des griefs contre la stratégie mais plutôt des doutes sur la capacité de certains à suivre et participer à cette évolution.
Et j’avoue que c’est mon cas.
Pour moi il y a deux sujets délicats:
- le passage progressif en POO qui je trouve complexifie le code pour souvent pas grand chose en retour (et je le maintiens)
- la complexité de l’environnement de développement et donc de son maintien en condition opérationnel
Ces sujets sont délicats pour ceux qui ne les manipulent pas tous les jours ce qui est mon cas. Et j’avoue que quand je me mets un peu le week-end devant un spip je n’ai pas envie de passer trop de temps à rétablir mon environnement et à me rappeler comment fonctionne tel ou tel concept de POO.
Ça me rappelle un peu dans les années 90 quand j’ai commencé à monter des PC et que je passais mon temps à les administrer plutôt qu’à jouer avec.
Je sais que vous n’êtes pas forcément d’accord car je pense que vous ne mesurez pas vraiment l’ampleur du sujet. Mais si on fait un constat, depuis peu d’années :
- On est passé sous GIT avec son environnement plus complexe à appréhender
- On utilise systématiquement des PR (j’ai vu passer des MR mais je ne sais pas ce que c’est)
- On utilise SEMVER plus précisément en prenant soin de respecter des conventions largement répandues (j’ai toujours rien compris au PSR)
- On a rajouté le changelog avec son format adapté
- On ajoute des librairies et de la POO dans le code spip
- et j’en oublie surement
Cela fait beaucoup quand on est pas un utilisateur quotidien de spip.
Mais voilà c’est le problème de ceux qui ne suivent pas ou difficilement, comme moi.
Maintenant la vraie question est : est-ce que ça pose un problème ? A cela je vous laisse répondre mais c’est important de comprendre qu’il est difficile pour moi et peut-être d’autres d’aider efficacement.
Enfin, il y a un autre sujet qui m’est peut-être plus propre. Je suis souvent plus intéressé par les chantiers conceptuels liés à spip voire à son écosystème. Aujourd’hui force est de constater que ça n’intéresse pratiquement plus personne en capacité d’orienter et de porter ces sujets.
C’est dommage même si je peux comprendre le pragmatisme actuel du au petit nombre de personnes en capacité de porter la stratégie.
Donc surtout, ne prenez pas ombrage des remarques car je pense que tout le monde comprend l’orientation et la supporte mais elle n’est pas une évidence pour tous.
Oui les changements sont délicats à appréhender. Mais on peut prendre aussi des cas inverses : des personnes qui debarquent depuis dehors de la communauté SPIP (on a eu un cas récemment via discord) et qui ne trouvent pas les conventions habituelles de la communauté PHP, notamment l’absence de POO (qui est plus complexe en première approche j’en conviens, mais qui facilite la maintenance dès que le code grossi).
Pour répondre à certaines de tes questions.
- Git plus complexe à apprendher en première approche oui. Mais permet aussi de mieux gérer certaines choses que notre historique svn (par exemple les reports).
- La différence entre PR et MR est purement terminologique. Mais disons qu’à partir du moment où tu crée une branche dans le meme depot puis propose la validation, c’est une MR (merge request : demande de fusion de 2 branches au sein d’un meme dépot). PR c’est lorsque tu propose une branche depuis un autre depot (Pull request). En pratique cependant les forges utilisent souvent un seul terme pour ces 2 choses. Gitea avait « Pull request », gitlab « Merge request ». Si tu interverti les 2 termes ca ne change pas grand chose.
Pour ce qui concerne le « est-ce que cela est important » j’ai envie de dire : le but de l’équipe de maintenance c’est toujours de proposer les même interface mais pas les memes implémentations (on peut faire sauter certaines interfaces ponctuellement, mais c’est documenté). Donc pour des personnes qui ne maintiennent pas le code de SPIP mais du code se basant sur SPIP, normalement il ne doit pas y avoir de surprise.
Je passe outre la question de l’instllation à dessins :
- normalement une installation en mode dev concerne uniquement une minorité de personns
- la doc est actualisé aussi régulièprement que nécessaire par james dans le README.md de spip : certes ca bouge parfois, mais normalement c’est à jour donc on peut s’y référer à chaque fois
- le fait qu’il y ait eu plusieurs changements ces derniers temps est aussi lié à une volonté de proposer de « forme intermédiaire » plus proches de ce qui existait avant comme pratique. Force est de constater que cela a peut être embrouillé plus qu’autre choses.
Par ailleurs, on pourrait aussi dire que si tout ces changements arrivent rapidement, c’est parce qu’ils ne sont pas arrivés au fur et à mesure… et donc qu’il y enormement de choses à rattraper si on veut pouvoir recruter de nouvelles personnes qui maintiennent.
Enfin sur les aspects conceptuels, etc : l’équipe de maintenance ne demande que cela d’avoir un roadmap fonctionnel. Mais effectivement elle n’a pas les forces pour porter le projet d’écriture de ce roadmap.
Oui, mais également en terme de syntaxe et de lecture…
Je donne un simple exemple :
A: [ a (#VAL{1}) b (#VAL{2}) c ]<br>
B: [ a (#VAL{1}) b [(#VAL{2}) c ]<br>
C: [ a (#VALUE) b (#VALUE) c ]<br>
D: [ a (#VALUE) b (#VALUE) c<br>
E: #AAA - #ZZZ<br>
F: #VAL{(#VAL{#VAL{1}}}
G: [(#VAL{(#VAL{#VAL{1}}})]
À votre avis, cela affiche quoi ?
Réponse
A: a 1 b (2) c
B: [ a (1) b 2 c
C:
D: [ a () b () c
E: #AAA -
F:
Et 2 erreurs :
- Filtre
)non défini ligne 13 - Filtre
G:non défini ligne 11
Mais:
- Il n’y a pas de
)ligne 13… ni même 11 - et le
G:est sur la ligne 13, pas 11
Tu vois que le compilateur doit faire des choix arbitraires parce que la syntaxe ne permet pas de distinguer explicitement ce qui est du texte de l’utilisateur, de ce qui est du langage de squelette : tout est mélangé… parfois le ( ou le [ ou le # doit être considéré texte, parfois langage… et ça c’est un problème fondamental déjà, ce que ESJ avait commencé à modifier en présentant une autre proposition à Avignon.
Et donc le phraseur fait des choix selon ses regexp qu’il est difficile d’anticiper en lisant le code : parfois ça lève des erreurs, parfois pas… et tu ne le sais qu’en exécutant le squelette, et tu dis aux gens : mettez crochets et parenthèses partout sur les balises… ce qui ne résout que partiellement le problème, en rendant les squelettes encore plus complexes à lire, ou échappez chaque [ ( # que vous voulez faire écrire. Et là encore c’est des cas assez simples.
Et en tant qu’humain·e et intégrateurice, bah ça peut être hyper fastidieux, source de bugs et d’incompréhensions… Et encore là c’est juste quelques balises simples… mais c’est pareil pour les critères et les boucles.
Tous les autres systèmes de template utilisent des délimiteurs précis de leur syntaxe, et c’est simplement pas pour rien… parce que sinon c’est très compliqué de savoir ce qui appartient à ton langage, de ce qui appartient à ce que veut écrire l’utilisateurice.
Dans l’état actuel de la syntaxe des squelettes SPIP, il est par construction difficile de faire mieux que cet état imprécis, dès que tu sors un peu d’une écriture idéale : et en fait ça arrive assez souvent ces cas. Et comme c’est imprécis par construction du langage, il est très difficile d’indiquer exactement où sont certaines erreurs lorsqu’un squelette est parsé.
Autre exemple là squelettes/contenu/auteur.html · 31991dc71e160d854f158f874c7a1164a3be4974 · spip / prive · GitLab tu vois le [ à la fin de [(#BOITE_OUVRIR{[`` : il appartient à qui ?
Bon courage 
!
Maieul, je ne demande pas à ce qu’on m’explique en quoi les modifications sont nécessaires et bonnes. Je suis d’accord.
Je dis juste en quoi ces modifications peuvent perturber certaines personnes qui maintiennent plus ou moins spip depuis des années comme moi.
Mais je répète il n’y a pas de doute sur ces orientations.
Oui enfin ça c’est l’arlésienne quand même.
Je pense que c’est bien d’y penser mais on ne peut pas dire que ce soit une réalité prégnante. Donc c’est bien aussi de garder les historiques
Non, ce qui est facile à maintenir c’est ce qui est compris, point.
Non plus. Et le fait que ça bouge peut être même nécessaire.
Je l’ai expérimenté par exemple sur la gestion des traductions mais rien de grave.
Oui mais je parle de ces personnes là dont moi-même.
Mais il n’y aurait pas quelques améliorations à apporter dans la syntaxe peut-être en la rendant plus restrictive ?
Bah justement, avoir plein de fonctions qui s’appellent mutuellement et se passe des arguments reciporiquement, à terme c’est moins compréhensibles que d’avoir des classes bien compartimentée avec des methodes petites et bien lisibles, un système de namespace qui évite d’avoir des noms à rallonge etc.
Mais par contre oui ca demande de comprendre un peu la POO au départ. Mais du coup c’est la meme chose pour tout en fait : si on n’apprend pas (et on peut avoir plein de bonne raisons pour ne pas apprendre) forcément à un moment ca devient plus compliqué. Mais pour les gens qui apprenennt les 2 methodes, à un moment oui la POO devient vraiment plus lisible. Question de courbe d’apprentissage sans doute.
Oui enfin ça c’est l’arlésienne quand même.
c’est peut ^'etre l’arlésienne parce qu’on ne s’est pas donné les moyens d’avoir un code conventionnel aussi. Et pour le coup depuis 4 mois on a eu 2 devs de plus dans l’équipe de maintenance + 1 personne qui vient de debarque sur discord, a l’habitude de bosser en PHP, et constate que le code de SPIP n’est pas compréhensible pour une autre culture que la culture spipienne.
Non plus. Et le fait que ça bouge peut être même nécessaire.
c’est bien pour cela que j’ai mis le normalement (cf aussi mes messages plus haut sur le fait toutes les ruptures de compat sont externalisés).
Mais il n’y aurait pas quelques améliorations à apporter dans la syntaxe peut-être en la rendant plus restrictive ?
c’est une question que je me suis posé. Mais ce serait un autre sujet non ? quelque chose pour une quiée @fonctionnel ?
Ya besoin d’expliquer, et @marcimat apporte là des raisons : le code historique est parfois tarbiscoté + la coloration du code, la gestion des erreurs et le debugage des squelettes et du code SPIP ne sont pas facilités par les IDE en raison des spécificités SPIP,…
Les exemples sont concrets et font écho à mon expérience, et à notre expérience à tous probablement, d’écriture de squelettes ou de codage PHP avec spip :
- « si tu surcharges
machin_dist()enmachin(): ton IDE ne le sais pas » - l’IDE « ne comprends pas non plus si tu fais
include_spip('inc/qqc'); »
Ça c’est « avant », et on peut savoir, nous, comment surcharge et inclusion se font « après » et sont mieux aidées par les IDE ?
Car causer par changelog et log de commit aux normes, c’est bien pour les machines, mais causer aux humains au fur et à mesure, ce serait top pour l’écosystème humain. Ça réduirait le fossé entre les trop peu nombreux auteurs de ces changements et les autres utilisateurs-devs.
Cette discussion y contribue mais ça pourrait être élargi, par petits bouts sympas sur ces forums au fur et à mesure, ou dans un fichier « changelog_pour_tous.md » lol… ou dans la mailing-lettre SPIP (yen a une en cours là ?).
Bah justement en pluscdes changelos (qui s’adressent a des humaine.es hein!) Il y a le fichier d’upgrade…