Je mets à jour ces derniers temps les plugins que je maintiens depuis des années et j’en suis à YAML et je voudrais partager avec vous les propositions qui suivent.
Pour mémoire, nous n’avons jamais voulu intégrer le plugin YAML ni aucun traitement du format YAML dans SPIP. Ca s’explique surtout eu égard au JSON qui est natif, plus performant et fonctionnellement équivalent mais on a quand même assumé pendant des années des entorses à cette vision :
Textwheel (TW) a décrit ses wheels en YAML jusqu’en 2021 et pour être autonome a embarqué une mini librairie YAML.
Les itérateurs fournissent une fonction de décodage du YAML pour la boucle DATA qui s’appuie sur la librairie YAML de Textwheel
En 2021, j’ai passé toutes les wheels de TW en JSON en conservant les YAML par précaution le temps de tester leur conformité et la librairie mini YAML de TW a été supprimée. TW autorise toujours les wheels en YAML pour assurer la compatibilité avec des plugins comme TODO qui définissent leurs propres wheels.
Donc depuis plusieurs versions nous avons des petites incohérences dans le Core et les plugins-dist:
La fonction inc_yaml_to_array_dist() qui fait l’include de inc/yaml-mini qui n’existe plus dans TW est totalement inutile car elle renvoie false si le plugin YAML n’est pas actif pour prendre la main et donc écraser cette fonction.
Les wheels YAML de TW ne sont plus utilisées et après 5 ans on peut dire que les wheels JSON fonctionnent
Indépendamment du plugin YAML lui-même qui finalement devient le seul fournisseur du format YAML, je propose les modifications suivantes dans SPIP :
Retirer la fonction inc_yaml_to_array_dist() des itérateurs : seul le plugin YAML fournira la fonction adéquate qui pourra d’ailleurs intégrer le suffixe _dist.
Retirer les wheels YAML de TW
Ces deux tickets pourraient être pris en compte dans une version de maintenance de SPIP 4.4 car ils ne changent rien et c’est presque du bugfix. Pour SPIP 5 je propose de déprécier complètement le YAML de TW ce qui demandera à quelques plugins de se réaligner (4) : accordion, colonne_raccourci, dame_blanche, latexwheel mais ce n’est pas obligatoire. Pour YAML en SPIP 5 je passerais sur la dernière version 8 de Symfony qui nécessite PHP8.4.
A vous lire et je créerais les tickets si on est d’accord.
Sur le fond je suis d’accord.
Mais je ne comprend pas la chronologie proposée.
D’un côté tu dis « Ces deux tickets pourraient être pris en compte dans une version de maintenance de SPIP 4.4 » (ce avec quoi je ne suis pas d’accord, mais peu importe pour l’instant). Et de l’autre tu parles d’attendre SPIP 5 pour déprécier complètement.
Je parle de déprécier les wheels en YAML, ce qui n’a rien à voir avec les deux tickets cités qui eux sont indépendants de la version SPIP. Aujourd’hui dans TW on regarde les wheels en JSON ou en YAML : je dis qu’autoriser les wheels en YAML pourrait etre supprimé en SPIP 5 et donc déprécié en SPIP 4.4.
En ce qui concerne ce que je trouve être du bugfix en SPIP 4.4 c’est un point de vue mais pour moi vu que ça ne change pas le comportement actuel et que c’est quand même des incohérences ça ma parait licite.
sauf que dans tes 2 points, il y aussi le retrait de l’iterateur en spip 4.4, qui ne me parait pas idéal. Mais le retrait des .yaml si on a les .json equivalent pour les wheels, oui !
je suis d’accord qu’il faudrait nettoyer mais on a jamais résolu le fait que les wheels en json ont perdu tous leurs commentaires. Ces dernières semaines j’ai du replonger dans tw pour faire du debug et des patch secu, et je me suis retrouvé à chaque fois à ouvrir les wheels yaml pour comprendre le fonctionnement car les wheels json sont sans explication…
Ben en fait, on peut dire que ça fait longtemps qu’il n’est plus actif. Si tu regardes le code actuel :
function inc_yaml_to_array_dist($data) {
include_spip('inc/yaml-mini');
if (!function_exists('yaml_decode')) {
throw new Exception('YAML: impossible de trouver la fonction yaml_decode');
return false;
}
return yaml_decode($data);
}
l’include renvoie false silencieusement car le fichier n’existe plus dans TW. Donc la fonction yaml_decode n’est jamais trouvée et ça renvoie une exception si le plugin YAML n’est pas actif : donc c’est pas loin d’être un bug non ?
Oui c’est exact c’est la seule contrainte je suis d’accord. Mais on a jamais voulu supporter YAML dans le core ou dans les plugin-dist : on est pas très cohérent sur le coup.
Ce qui est sur c’est que je pense qu’on passe toujours par le YAML pour écrire la wheel puis après on traduit en JSON. Mais c’est vrai qu’au niveau des performances le JSON est meilleur.
JSON n’est pas censé un jour accepter les commentaires ? Ou un fichier md qui décrit les wheels si besoin pour les cas tordus - ou pas ?
l’include renvoie false silencieusement car le fichier n’existe plus dans TW. Donc la fonction yaml_decode n’est jamais trouvée et ça renvoie une exception si le plugin YAML n’est pas actif : donc c’est pas loin d’être un bug non ?
bah non il est pas silencieux ! mais ok dans cette mesure pour supprimner, même si je n’en voie pas l’urgence pour autant
Bah si : l’include renvoie false sans qu’on le teste donc silencieusement, c’est l’existence de la fonction qu’on gère.
Ah la sempiternelle ritournelle : j’avoue ne pas comprendre l’intérêt d’accumuler de la dette si on peut corriger sans ouvrir un chantier ce qui est le cas. Mais je pense que c’est un autre sujet qui ne sert à rien d’être débattu ici.
provoquer une erreur n’est pas être silencieux ^^ à mon sens. mais bon question de vocabulaire.
bref, paye ta MR.
Juste par rapport à ta question : comme le process de dev par de spip 5 pour faire des reports en spip 4.4, suppriner enb 4.4 demande un peu plus de travail. Et en plus même si c’est purement formel, cela revient à supprimer quelque chose, donc ca casse la logique semver, même si le quielque chose en question est quasi inexistant.
Euh franchement si vous préférez garder SPIP 4.4 intact avec ces incohérences je vais pas me battre. Donc on fait des tickets pour SPIP 5 et c’est tout. Comme ça je vais m’atteler à YAML car y a quand même des choses pas très propres dedans indépendamment de SPIP lui-même.
: l’include renvoie false sans qu’on le teste donc silencieusement, c’est l’existence de la fonction qu’on gère.