Posté par Psychofox (Mastodon) .
Évalué à 5.
Dernière modification le 12 janvier 2023 à 14:16.
J'avais déjà lu un article proche (j'ignore si l'auteur est le même) et c'est vrai que je ne vois pas bien l'avantage de yaml en terme de visibilité comparé à json.
Sans compter les exemples exposés dans cet article on a moins d'accolades à taper certe mais on se retrouve à faire de la merde pour un espace en trop ou en moins.
Derrière le terme à la mode devops se cache des millions de gens qui s'arrachent les cheveux chaque jour pour réparer des erreurs de syntaxe dans des fichiers YAML. C'est tout de suite moins sexy.
Et le pire c'est que le JSON en avait mais ils ont été supprimés :
As we saw before, json had comments very early on, but they were removed because people started putting parsing directives in there. I think this is the right call for a serialization format, but it makes json unsuitable as a configuration language.)
C'est fort dommage, c'est le seul truc qu'il lui manque.
Ça permet de commenter les objets mais pas les champs. Le commentaire que tu as mis au dessus de buffer sera placé ailleurs selon que l'outil utilisé pour afficher le Json réordonne les clés ou pas.
Ça permet de commenter les objets mais pas les champs. Le commentaire que tu as mis au dessus de buffer sera placé ailleurs selon que l'outil utilisé pour afficher le Json réordonne les clés ou pas
à partir du moment où on utilise plus qu'un 'simple' éditeur de texte (notepadd++, emacs, vim, kate…) pour éditer une conf, je verrai d'un très mauvais œil qu'il réordonne les clés, commentaire ou pas.
Alors oui l’ordonnancement des clés n'est pas garanti par la norme json, mais si je veux modifier une conf via un outils, j'en prendrai un qui garde l'ordre.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Posté par Psychofox (Mastodon) .
Évalué à 5.
Dernière modification le 12 janvier 2023 à 15:34.
En l'occurence tu peux.
Par le créateur de JSON:
JSON does not have comments. A JSON encoder MUST NOT output comments.
A JSON decoder MAY accept and ignore comments.
En gros il est interdit à un programme qui produit du json d'en fournir à la sortie, par contre il est autorisé de mettre des commentaires et de les faire ingérer par un parser/decoder json.
En l'occurence c'est à ça que sert la lib JSON.minify qui est disponible pour plein de langages et permet d'ignorer les commentaires au format C/C++
Il est aussi possible d'ajouter des clé commentaires de ce type:
Et t'assurer que le programme qui le mange ignore toutes les clés avec le suffixe _comment.
De toute façon il n'y a plus rien qui ne passe pas par une moulinette via une intégration continue de nos jours donc c'est relativement facile de poutrer les commentaires à ce moment là.
Les clés commentaires, ça me parait pas super élégant, ni facilement intégrable à un éditeur de façon générique.
C'est comme dire "on peut supprimer les commentaires du C, suffit de mettre une chaine qu'on utilise pas et que le compilo va retirer du binaire". Ça fait le travail, mais c'est pas super beau.
Par exemple si le fichier JSON peut être affiché sous forme d'un formulaire:
Les clés servent à définir les étiquettes de chaque champ
Les valeurs sont le contenu des champs
Les "commentaires" peuvent être affichés sous forme de documentation
Dans ce type d'usage, le commentaire est donc une vraie donnée qui peut être exploitée par les outils manipulant le fichier. C'est mieux de faire comme ça que de parser des commentaires qui seraient présents dans le fichier (ce qui s'est passé quand il y avait des commentaires dans la spécification JSON: certains outils ont commencé à les utiliser comme métadonnées ou annotations).
Posté par Faya .
Évalué à 7.
Dernière modification le 12 janvier 2023 à 22:10.
ce qui s'est passé quand il y avait des commentaires dans la spécification JSON: certains outils ont commencé à les utiliser comme métadonnées ou annotations
Wikipédia dit : "Durant la mise au point du format, Douglas Crockford constate que certains des premiers utilisateurs du JSON ajoutent des commentaires dans le but de donner des directives au parser, à l'image des instructions #ifdef ou #define du préprocesseur C. Il y voit un danger pour l'interopérabilité, une priorité du format, et décide de les retirer. En 2012, il s'explique sur ce choix et reconnait être conscient de la tristesse des utilisateurs de ne pouvoir commenter ces fichiers." Sauf qu'il a publié son explication sur Google+ (la source fournie par Wikipédia) et que son commentaire est maintenant inaccessible… Même l'archive Wikiwix n'affiche que du JS minifié.
C'était bien la peine de nous supprimer une feature parce qu'il était tant inquiet pour l'interopérabilité, tout en fournissant l'explication sur un silo de données qui a coulé depuis :-)
je ne vois pas bien l'avantage de yaml en terme de visibilité comparé à json.
Attention que le pseudo json que tu fais à la main est déjà une forme de yaml qui s'ignore. Normalement tu ne devrais pas avoir ces retours à la ligne et indentations qui te rendent le json si sympa en apparence car c'est de la sérialisation et non un truc prévu pour être facile à traiter par l'humain (là dessus xml est plus sympa.)
on a moins d'accolades à taper certe mais on se retrouve à faire de la merde pour un espace en trop ou en moins.
Pourtant on nous rabâche que l'espacement c'est ce qu'il y a de mieux et Pythonique. Plusieurs poids plusieurs mesures ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Pourtant on nous rabâche que l'espacement c'est ce qu'il y a de mieux et Pythonique. Plusieurs poids plusieurs mesures ?
J'ai toujours trouvé que les bloc par indentation c'était une connerie, dès qu'on bosse à plusieurs sur un fichier c'est source d'erreurs; dès qu'on fait de gros changement dans les logique et niveau d'indentation faut vérifier plusieurs fois qu'on a pas fait une connerie/
(là dessus xml est plus sympa.)
Tu plaisantes? l'indentation en xml est tout autant optionnelle; tout comme les retours à la ligne. C'est même pire, les espaces et les retours à la lignes sont même capturé par characters() dans les parseurs; c'est optionnel parce que les outils décident de les ignorer.
Typiquement dans le code suivant ta ligne va commencer par "\n ", et terminer par "\n "
[...]
<plop>
maligne super longue que j'ai pas envie de séparer sur quinze lignes et garder les balise visible dans mon éditeur
</plop>
[...]
Dans le json, les blancs retour a la lignes (hors "") sont ignorés dans la norme (et pas par convention)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Je disais plus sympa parce-que optionnel (tu peux en mettre mais ce ne sera pas pris en compte à l'arrivée) alors que pour l'autre ce n'est pas permis. Bien entendu en parlant de la norme dans les deux cas.
Les blocs par indentation ce n'est pas aussi con que tu le penses ; ce n'est pas pour rien que même dans les langages à forme libre on l'applique. Par contre, là où c'est une aide pour rendre le code compréhensible par les êtres humains, c'est devenu une obligation pour que le code soit compréhensible par la machine ; et la beauté paradoxale du truc c'est que Python a réintroduit un truc que Fortran a laissé tombé (et qui se justifiait à l'époque des cartes perforées.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par fearan .
Évalué à 5.
Dernière modification le 13 janvier 2023 à 08:00.
Je disais plus sympa parce-que optionnel (tu peux en mettre mais ce ne sera pas pris en compte à l'arrivée)
Justement, non, en json tes espaces hors "" sont ignorés c'est la norme, c'est permis, en xml il sont de la donnée; modifier l'indentation de ton xml c'est modifier ses données, reformater ton xml c'est modifier ses données; là où formatter un json ne change absolument rien aux données.
Par contre, là où c'est une aide pour rendre le code compréhensible par les êtres humains, c'est devenu une obligation pour que le code soit compréhensible par la machine
N'importe quel éditeur digne de ce nom est capable de ré-indenter un code mal indenté; et même certains t'indique qu'une ligne est mal indenté tout court; on a même des outils comme sonar qui repèrent ce genre de bourde.
Une ligne mal indenté ça peut vouloir dire 2 chose :
il manque des espaces (ou tabulation selon la norme locale)
elle est pas dans le bon bloc (étourderie, merge, pas mal d'itération de mise au point…
en python une telle erreur est indétectable
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Posté par Psychofox (Mastodon) .
Évalué à 3.
Dernière modification le 12 janvier 2023 à 22:59.
Attention que le pseudo json que tu fais à la main est déjà une forme de yaml qui s'ignore. Normalement tu ne devrais pas avoir ces retours à la ligne et indentations qui te rendent le json si sympa en apparence car c'est de la sérialisation et non un truc prévu pour être facile à traiter par l'humain (là dessus xml est plus sympa.)
C'est ce que je dis plus haut. En sortie pas de commentaires et d'espaces, en entrée pour de la config comme c'est toi qui maitrise le parser/décodeur tu fais ce que tu veux.
Il faut bien séparer l'usage du json comme format d'échange de données entre deux programmes de l'usage du json comme format d'entrée de données de configuration.
Dans le premier la question des commentaires ne se pose pas car ça n'a aucun intérêt, dans le second tu as cette liberté. Idem pour les retours à la ligne pour la lisibilité dans ton repos git que tu fais sauter allègrement si tu veux l'envoyée dans l'entrée standard d'une cli.
Pourtant on nous rabâche que l'espacement c'est ce qu'il y a de mieux et Pythonique. Plusieurs poids plusieurs mesures ?
Ben moi j'ai toujours préféré ruby à python donc je n'ai jamais adhéré à cette école.
Et accessoirement aujourd'hui au boulot j'ai écris du Perl5 pour un truc qui tourne en serverless dans le nuage, c'est pas bô? Et j'ai trouvé ça bien plus agréable que la dernière fois que j'ai écris du python. Comme quoi pas si facile d'enterrer les dinosaures.
Nous sommes d'accord : c'est un format d'échange. La conf c'est un usage détourné pour lequel tu pourrais utiliser TOML par exemple. C'était l'essence de mon propos.
Par contre, si tu n'es pas dans la mouvance Python alors ta critique initiale fait/est sens/cohérente. Longue vie aux pierres précieuses (tiens, tu me rappelles que j'avais posté un lien sur le dernier où certains commentaires se sont évertués à indiquer que ce devait être enterré) :)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[…] je ne vois pas bien l'avantage de yaml en terme de visibilité comparé à json.
Les commentaires c'est très confortable. On trouve des pis-aller en json mais rien qui ne permette d'écrire ça il me semble :
value:-foo# à dommenter si vous voulais des bar#-bar
De plus je ne connais aucun éditeur capable de rendre un commentaire json… (pour le json standard en json5 c'est un peu différent).
yaml est aussi très pratique lorsque tu veut des chaînes de caractères multi-lignes. Par exemple j'ai un outil de requête http dans le quel des fichiers yaml décrivent la requête complète à exécuter et les vérifications à faire sur la réponse. C'est très confortable de pouvoir mettre tout le corps de la requête dans le même fichier que le reste et que tout reste lisible.
yaml va bien plus loin avec du multi document dans un même fichier ce qui est bien plus agréable que de créer un tableau avec des json dedans.
Enfin yaml a des références. Je m'en sert que pour l'intégration continue de gitlab où ça nous sert à factoriser certaines portions.
C'est une format complexe et je n'aurais vraiment pas envi d'écrire un parseur et ça me choque pas de lui préférer toml, json ou d'autres. Mais il n'est clairement pas dénué d'intérêt.
Derrière le terme à la mode devops se cache des millions de gens qui s'arrachent les cheveux chaque jour pour réparer des erreurs de syntaxe dans des fichiers YAML. C'est tout de suite moins sexy.
Et des milliards aussi, non ? Ceux qui souffrent ainsi sont les personnes qui utilisent très peu yaml avec des outils mal conçus. python et make ont exactement le même genre de problèmes et ça ne semble pas rendre les lycéens accros à la meth. Quand j'ai appris C++, si tu oubliais un point-virgule à la fin d'une classe, le compilateur te vomissait dessus tous ce qu'il pouvait pour te faire comprendre que t'étais une merde. Il semble que ça n'ai pas empêché le langage d'être massivement utilisé.
Personnellement je galère quand je fais de l'ASN1, mais je crois avoir ici des gens qui trouvent le format génial.
-name:Display error messagedebug:msg:>-Check the "nickname" displayed in thecolumn 3
[{"name":"Display error message","debug":{"msg":"Check the \"nickname\" displayed in the column 3"}}]
-name:Display error messagedebug:msg:|-Check the "nickname" displayed in the column 3.You may also check the firstname in column 4.This feature makes YAML very easy to read.
[{"name":"Display error message","debug":{"msg":"Check the \"nickname\" displayed in the column 3.\nYou may also check the firstname in column 4.\nThis feature makes YAML very easy to read."}}]
Les critiques que j'ai vu dans ce post sont de mauvaise foi. Le format yaml est fait pour les humains, et permet de spécifier des valeurs sans avoir à utiliser des guillemets.
Pour les valeurs qui posent problème, ajouter des guillemets suffit, et un bon éditeur de texte affiche une notice ou même une erreur automatiquement.
Le format JSON est adapté à l'échange de données automatique, et le format YAML est fait pour être lu et maintenu par les développeurs. Ce n'est pas comparable, et ne doit pas l'être.
En plus, comme je dis souvent, YAML est pour faire de la configuration documentée et non pour faire de l'échange de données entre machines/programmes …tandis que JSON c'est l'exact opposé. Mais les gens veulent détourner ce dernier pour faire de la conf pfff.
Comme j'aime aussi à dire, les gens qui râlent qu'ils ou elles préfèrent du JSON ne veulent juste pas comprendre qu'elles ou ils sont en train de faire du YAML compacté …puisque c'est un sur-ensemble de l'autre ! Pour prendre un exemple similaire :
persona:name:Mikepets:-Lacy-Garfild-Fliper
…est la forme entièrement dépliée que n'importe qui ne travaillant pas dans l'informatique comprend aisément.
Dans les cas simples comme celui-là, on peut écrire la liste sous forme un peu plus compacte (et je recommande quand ce sont de petites listes —ici trois éléments— composées de petits éléments —ici des mots et non de longues phrases— et qu'il y a beaucoup de paires —histoire de tenir sur moins de lignes et de ne pas avoir à faire défiler— …3 conditions courantes)
persona:name:Mikepets:[Lacy,Garfild,Fliper]
…on peut continuer à regrouper (ou replier/compacter d'un cran ?) ; c'est toujours du YAML
persona:{name:Mike,pets:[Lacy,Garfild,Fliper]}
Un petit air familier ? La seule contrainte est ça fonctionne en cascade (comme des poupées gigognes) : on ne peut/doit pas plier un niveau sans plier les niveaux en dessous :
Mais les formes plus ou moins compactées gardent une certaine liberté pratique…
persona:{name:Mike,pets:[Lacy,Garfild,Fliper]}
Toujours familier ? Sauf que c'est du YAML… Ce n'est pas parce-que l'éditeur de texte offre cette facilité que c'est du JSON : ça marche parce-que derrière il y a un autre outil qui doit se taper du boulot pour en faire un vrai JSON :
Et même à ce niveau, on peut apprécier la simplicité du YAML qui n'impose pas de quoter quand ce n'est pas ambigu (normal, c'est pour les humains et ces êtres n'aiment pas quand c'est trop rigide…) Ce qui fait qu'on peut avoir simplement :
{persona:{name:Mike,pets:[Lacy,Garfild,Fliper]}}
Dans tous ces derniers cas, Lesieur ne sachant pas qu'il fait de la prose va se monter la mayo. Alors calm down les yamlhaters ; vous voulez juste réduire le multivers Marvel à la petite chambrette que vous connaissez et priver les autres de la richesse qui vous dépasse. Grandissons et cessons de comparer le ragout à la patate cuite ;p
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par barmic 🦦 .
Évalué à 2.
Dernière modification le 14 janvier 2023 à 10:42.
En plus, comme je dis souvent, YAML est pour faire de la configuration documentée et non pour faire de l'échange de données entre machines/programmes …tandis que JSON c'est l'exact opposé. Mais les gens veulent détourner ce dernier pour faire de la conf pfff.
Ça peut devenir subtile comme frontière. Quand j'expose un contrat OpenAPI en http pour que ce soit manipulé ensuite par un générateur de code ou une gateway c'est de quel côté ?
Json est dans un paquet de bibliothèques standard là où yaml non ajouter une dépendance en plus ou avoir un peu moins bien ça se questionne.
Et json est un bon format d'échange quand tu veux être lisible par un humain sinon tu as tout un tas de format qui seront meilleur en temps de serialisation, taille serailisé ET temps de déserialisation.
Au final json est un format d'ubiquité beaucoup de langages l'ont dans leur bibliothèque standard, la majorité des éditeurs le manipulent correctement sans configuration préalable, il est simple, il est connu et largement utilisé, comme pi aller au problème de perf il se compresse pas trop mal (mais ça reste moins bon que des formats compact de base). C'est évident qu'il est utilisé partout et pour tout.
contrat en http & manipulé par un générateur de code ou une gateway
C'est bien du côté échange de données sérialisées par/pour machines
Bon, c'est de l'OPenAPI qui est la variante description de conf documentée par/pour les humains …de JSON-Schema. On a donc la possibilité de mettre des commentaires (dont les machines se contrefichent), d'utiliser des références et de la composition comme facilités (dont les machines entre elles n'ont que faire entre elles) etc.
Tout comme JSON, YAML ne m'a jamais fait défaut et souvent les deux sont en standard soit en dépendance (mais disponibles et matures comme bibliothèques) donc kif-kif pour moi.
On est d'accord que Luc BSON est meilleur, et il est de plus en plus pris en charge.
Après, je ne remets pas en cause le fait que les gens veulent se contenter d'un pis-aller mais les articles et billets qui se lancent dans des comparaisons qui n'ont pas lieu d'être pour forcer les autres à adopter leur point de vue qui n'est finalement que du dogmatisme et de la foi religieuse.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Tout comme JSON, YAML ne m'a jamais fait défaut et souvent les deux sont en standard soit en dépendance (mais disponibles et matures comme bibliothèques) donc kif-kif pour moi.
On voit souvent dans les commentaires ici des gens utiliser le nombre de dépendance comme métrique de "mauvais" logiciels
Une bibliothèque c'est toujours, et particulièrement dans ce cas, une source de faille en plus donc de nouvelles CVE. Particulièrement pour un format comme yaml qui est plus complexe que json
Tous les langages ne sont pas fans des dépendances. Je pense à go, mais aussi à C ou C++ pour les quel la gestion des dépendances n'est pas aussi sympa qu'en rust par exemple
Pour les valeurs qui posent problème, ajouter des guillemets suffit, et un bon éditeur de texte affiche une notice ou même une erreur automatiquement.
J'aime bien le yaml, mais je trouve que c'est une critique valide, surtout qu'il y a des synonyme. Il faut savoir que mettre no ne va pas avoir la même signification que "no" alors que ce ne n'est pas le cas avec not et et "not" par exemple, alors qu'il existe true et false (bon, je crois que ce cas a été corrigé dans les normes récentes mais c'est encore comme ça que ça fonctionne dans la plupart des parsers). Ce n'est pas du tout pratique pour un format très répandu. Surtout que quelqu'un qui ne connaît pas encore bien le format, il n'a pas encore bien configuré son éditeur de texte.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# devops
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 12 janvier 2023 à 14:16.
J'avais déjà lu un article proche (j'ignore si l'auteur est le même) et c'est vrai que je ne vois pas bien l'avantage de yaml en terme de visibilité comparé à json.
Sans compter les exemples exposés dans cet article on a moins d'accolades à taper certe mais on se retrouve à faire de la merde pour un espace en trop ou en moins.
Derrière le terme à la mode devops se cache des millions de gens qui s'arrachent les cheveux chaque jour pour réparer des erreurs de syntaxe dans des fichiers YAML. C'est tout de suite moins sexy.
[^] # Re: devops
Posté par Jérôme FIX (site web personnel) . Évalué à 8. Dernière modification le 12 janvier 2023 à 14:40.
Un avantage : pouvoir ajouter des commentaires.
Pour des fichiers de configuration c'est pour moi essentiel
[^] # Re: devops
Posté par Faya . Évalué à 5.
Et le pire c'est que le JSON en avait mais ils ont été supprimés :
C'est fort dommage, c'est le seul truc qu'il lui manque.
[^] # Re: devops
Posté par fearan . Évalué à 5. Dernière modification le 12 janvier 2023 à 15:24.
En même temps si t'es pas strict au niveau du parsing (ie rejeter si balise inconnue), tu peux en mettre du genre
et selon le parseur on est même pas obligé d'ajouter des " autour des clés
par contre les clés devant être unique faut ajouter un truc ce qui peut devenir fastidieux
à noter que la norme ECMA-404 autorise les duplicate key ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: devops
Posté par Julien Jorge (site web personnel) . Évalué à 2. Dernière modification le 12 janvier 2023 à 21:12.
Ça permet de commenter les objets mais pas les champs. Le commentaire que tu as mis au dessus de
buffersera placé ailleurs selon que l'outil utilisé pour afficher le Json réordonne les clés ou pas.[^] # Re: devops
Posté par fearan . Évalué à 3.
à partir du moment où on utilise plus qu'un 'simple' éditeur de texte (notepadd++, emacs, vim, kate…) pour éditer une conf, je verrai d'un très mauvais œil qu'il réordonne les clés, commentaire ou pas.
Alors oui l’ordonnancement des clés n'est pas garanti par la norme json, mais si je veux modifier une conf via un outils, j'en prendrai un qui garde l'ordre.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: devops
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 12 janvier 2023 à 15:34.
En l'occurence tu peux.
Par le créateur de JSON:
En gros il est interdit à un programme qui produit du json d'en fournir à la sortie, par contre il est autorisé de mettre des commentaires et de les faire ingérer par un parser/decoder json.
En l'occurence c'est à ça que sert la lib JSON.minify qui est disponible pour plein de langages et permet d'ignorer les commentaires au format C/C++
Il est aussi possible d'ajouter des clé commentaires de ce type:
{
"key1":"foo",
"key1_comment":"blah blah blah",
"key2":"bar",
"key2_comment":"blah blah blah"
}
Et t'assurer que le programme qui le mange ignore toutes les clés avec le suffixe _comment.
De toute façon il n'y a plus rien qui ne passe pas par une moulinette via une intégration continue de nos jours donc c'est relativement facile de poutrer les commentaires à ce moment là.
[^] # Re: devops
Posté par Jérôme FIX (site web personnel) . Évalué à 7.
Cela ne ressemblerai pas à des mécanismes pour combler justement ce manque ?
[^] # Re: devops
Posté par gUI (Mastodon) . Évalué à 5.
J'avoue que décréter que n'importe quelle ligne commençant par '#' doit être exclue du parsing, ça coûte pas grand chose, et ça sauve des vies.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: devops
Posté par Misc (site web personnel) . Évalué à 10.
Les clés commentaires, ça me parait pas super élégant, ni facilement intégrable à un éditeur de façon générique.
C'est comme dire "on peut supprimer les commentaires du C, suffit de mettre une chaine qu'on utilise pas et que le compilo va retirer du binaire". Ça fait le travail, mais c'est pas super beau.
[^] # Re: devops
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 12 janvier 2023 à 20:14.
Pas forcément.
Par exemple si le fichier JSON peut être affiché sous forme d'un formulaire:
Dans ce type d'usage, le commentaire est donc une vraie donnée qui peut être exploitée par les outils manipulant le fichier. C'est mieux de faire comme ça que de parser des commentaires qui seraient présents dans le fichier (ce qui s'est passé quand il y avait des commentaires dans la spécification JSON: certains outils ont commencé à les utiliser comme métadonnées ou annotations).
[^] # Re: devops
Posté par Faya . Évalué à 7. Dernière modification le 12 janvier 2023 à 22:10.
Wikipédia dit : "Durant la mise au point du format, Douglas Crockford constate que certains des premiers utilisateurs du JSON ajoutent des commentaires dans le but de donner des directives au parser, à l'image des instructions #ifdef ou #define du préprocesseur C. Il y voit un danger pour l'interopérabilité, une priorité du format, et décide de les retirer. En 2012, il s'explique sur ce choix et reconnait être conscient de la tristesse des utilisateurs de ne pouvoir commenter ces fichiers." Sauf qu'il a publié son explication sur Google+ (la source fournie par Wikipédia) et que son commentaire est maintenant inaccessible… Même l'archive Wikiwix n'affiche que du JS minifié.
C'était bien la peine de nous supprimer une feature parce qu'il était tant inquiet pour l'interopérabilité, tout en fournissant l'explication sur un silo de données qui a coulé depuis :-)
[EDIT] OK j'arrête la mauvaise foi, Wikipedia Anglais donne une autre archive accessible : https://archive.ph/2015.07.04-102718/https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr#selection-695.158-695.163
[^] # Re: devops
Posté par David Delassus (site web personnel) . Évalué à 3.
Côté devops, on voit le language de configuration CUE qui prend du terrain.
On a aussi HCL côté Hashicorp (terraform, vault, …).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: devops
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Attention que le pseudo json que tu fais à la main est déjà une forme de yaml qui s'ignore. Normalement tu ne devrais pas avoir ces retours à la ligne et indentations qui te rendent le json si sympa en apparence car c'est de la sérialisation et non un truc prévu pour être facile à traiter par l'humain (là dessus xml est plus sympa.)
Pourtant on nous rabâche que l'espacement c'est ce qu'il y a de mieux et Pythonique. Plusieurs poids plusieurs mesures ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: devops
Posté par fearan . Évalué à 5.
J'ai toujours trouvé que les bloc par indentation c'était une connerie, dès qu'on bosse à plusieurs sur un fichier c'est source d'erreurs; dès qu'on fait de gros changement dans les logique et niveau d'indentation faut vérifier plusieurs fois qu'on a pas fait une connerie/
Tu plaisantes? l'indentation en xml est tout autant optionnelle; tout comme les retours à la ligne. C'est même pire, les espaces et les retours à la lignes sont même capturé par characters() dans les parseurs; c'est optionnel parce que les outils décident de les ignorer.
Typiquement dans le code suivant ta ligne va commencer par "\n ", et terminer par "\n "
Dans le json, les blancs retour a la lignes (hors "") sont ignorés dans la norme (et pas par convention)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: devops
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je disais plus sympa parce-que optionnel (tu peux en mettre mais ce ne sera pas pris en compte à l'arrivée) alors que pour l'autre ce n'est pas permis. Bien entendu en parlant de la norme dans les deux cas.
Les blocs par indentation ce n'est pas aussi con que tu le penses ; ce n'est pas pour rien que même dans les langages à forme libre on l'applique. Par contre, là où c'est une aide pour rendre le code compréhensible par les êtres humains, c'est devenu une obligation pour que le code soit compréhensible par la machine ; et la beauté paradoxale du truc c'est que Python a réintroduit un truc que Fortran a laissé tombé (et qui se justifiait à l'époque des cartes perforées.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: devops
Posté par fearan . Évalué à 5. Dernière modification le 13 janvier 2023 à 08:00.
Justement, non, en json tes espaces hors "" sont ignorés c'est la norme, c'est permis, en xml il sont de la donnée; modifier l'indentation de ton xml c'est modifier ses données, reformater ton xml c'est modifier ses données; là où formatter un json ne change absolument rien aux données.
tu peux regarder les flow ici, c'est super simple ;)
https://www.json.org/json-en.html
N'importe quel éditeur digne de ce nom est capable de ré-indenter un code mal indenté; et même certains t'indique qu'une ligne est mal indenté tout court; on a même des outils comme sonar qui repèrent ce genre de bourde.
Une ligne mal indenté ça peut vouloir dire 2 chose :
en python une telle erreur est indétectable
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: devops
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 12 janvier 2023 à 22:59.
C'est ce que je dis plus haut. En sortie pas de commentaires et d'espaces, en entrée pour de la config comme c'est toi qui maitrise le parser/décodeur tu fais ce que tu veux.
Il faut bien séparer l'usage du json comme format d'échange de données entre deux programmes de l'usage du json comme format d'entrée de données de configuration.
Dans le premier la question des commentaires ne se pose pas car ça n'a aucun intérêt, dans le second tu as cette liberté. Idem pour les retours à la ligne pour la lisibilité dans ton repos git que tu fais sauter allègrement si tu veux l'envoyée dans l'entrée standard d'une cli.
Ben moi j'ai toujours préféré ruby à python donc je n'ai jamais adhéré à cette école.
Et accessoirement aujourd'hui au boulot j'ai écris du Perl5 pour un truc qui tourne en serverless dans le nuage, c'est pas bô? Et j'ai trouvé ça bien plus agréable que la dernière fois que j'ai écris du python. Comme quoi pas si facile d'enterrer les dinosaures.
[^] # Re: devops
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Nous sommes d'accord : c'est un format d'échange. La conf c'est un usage détourné pour lequel tu pourrais utiliser TOML par exemple. C'était l'essence de mon propos.
Par contre, si tu n'es pas dans la mouvance Python alors ta critique initiale fait/est sens/cohérente. Longue vie aux pierres précieuses (tiens, tu me rappelles que j'avais posté un lien sur le dernier où certains commentaires se sont évertués à indiquer que ce devait être enterré) :)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: devops
Posté par barmic 🦦 . Évalué à 3.
Les commentaires c'est très confortable. On trouve des pis-aller en json mais rien qui ne permette d'écrire ça il me semble :
De plus je ne connais aucun éditeur capable de rendre un commentaire json… (pour le json standard en json5 c'est un peu différent).
yaml est aussi très pratique lorsque tu veut des chaînes de caractères multi-lignes. Par exemple j'ai un outil de requête http dans le quel des fichiers yaml décrivent la requête complète à exécuter et les vérifications à faire sur la réponse. C'est très confortable de pouvoir mettre tout le corps de la requête dans le même fichier que le reste et que tout reste lisible.
yaml va bien plus loin avec du multi document dans un même fichier ce qui est bien plus agréable que de créer un tableau avec des json dedans.
Enfin yaml a des références. Je m'en sert que pour l'intégration continue de gitlab où ça nous sert à factoriser certaines portions.
C'est une format complexe et je n'aurais vraiment pas envi d'écrire un parseur et ça me choque pas de lui préférer toml, json ou d'autres. Mais il n'est clairement pas dénué d'intérêt.
Et des milliards aussi, non ? Ceux qui souffrent ainsi sont les personnes qui utilisent très peu yaml avec des outils mal conçus. python et make ont exactement le même genre de problèmes et ça ne semble pas rendre les lycéens accros à la meth. Quand j'ai appris C++, si tu oubliais un point-virgule à la fin d'une classe, le compilateur te vomissait dessus tous ce qu'il pouvait pour te faire comprendre que t'étais une merde. Il semble que ça n'ai pas empêché le langage d'être massivement utilisé.
Personnellement je galère quand je fais de l'ASN1, mais je crois avoir ici des gens qui trouvent le format génial.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# coherentyaml
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Cela a rappelle que j'avais tenté un système de schéma pour se faciliter la vie :
https://github.com/nicolasboulay/coherentyaml
"La première sécurité est la liberté"
# J'aime le yaml
Posté par Andre Rodier (site web personnel) . Évalué à 5. Dernière modification le 13 janvier 2023 à 19:26.
Je préfère largement yaml à json, pour de multiple raisons.
Sans parler les fonctions avancées de référence, il y a des avantages énormes, AMHA.
Le rapport signal / bruit n'est pas comparable.
En json, ça donne quelque chose comme :
Le formatage de blocs de texte
Les critiques que j'ai vu dans ce post sont de mauvaise foi. Le format yaml est fait pour les humains, et permet de spécifier des valeurs sans avoir à utiliser des guillemets.
Pour les valeurs qui posent problème, ajouter des guillemets suffit, et un bon éditeur de texte affiche une notice ou même une erreur automatiquement.
Le format JSON est adapté à l'échange de données automatique, et le format YAML est fait pour être lu et maintenu par les développeurs. Ce n'est pas comparable, et ne doit pas l'être.
Plus d'exemples: https://yaml-multiline.info/
[^] # Re: J'aime le yaml
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
En plus, comme je dis souvent, YAML est pour faire de la configuration documentée et non pour faire de l'échange de données entre machines/programmes …tandis que JSON c'est l'exact opposé. Mais les gens veulent détourner ce dernier pour faire de la conf pfff.
Comme j'aime aussi à dire, les gens qui râlent qu'ils ou elles préfèrent du JSON ne veulent juste pas comprendre qu'elles ou ils sont en train de faire du YAML compacté …puisque c'est un sur-ensemble de l'autre ! Pour prendre un exemple similaire :
…est la forme entièrement dépliée que n'importe qui ne travaillant pas dans l'informatique comprend aisément.
Dans les cas simples comme celui-là, on peut écrire la liste sous forme un peu plus compacte (et je recommande quand ce sont de petites listes —ici trois éléments— composées de petits éléments —ici des mots et non de longues phrases— et qu'il y a beaucoup de paires —histoire de tenir sur moins de lignes et de ne pas avoir à faire défiler— …3 conditions courantes)
…on peut continuer à regrouper (ou replier/compacter d'un cran ?) ; c'est toujours du YAML
Un petit air familier ? La seule contrainte est ça fonctionne en cascade (comme des poupées gigognes) : on ne peut/doit pas plier un niveau sans plier les niveaux en dessous :
Mais les formes plus ou moins compactées gardent une certaine liberté pratique…
Toujours familier ? Sauf que c'est du YAML… Ce n'est pas parce-que l'éditeur de texte offre cette facilité que c'est du JSON : ça marche parce-que derrière il y a un autre outil qui doit se taper du boulot pour en faire un vrai JSON :
Et même à ce niveau, on peut apprécier la simplicité du YAML qui n'impose pas de quoter quand ce n'est pas ambigu (normal, c'est pour les humains et ces êtres n'aiment pas quand c'est trop rigide…) Ce qui fait qu'on peut avoir simplement :
Dans tous ces derniers cas, Lesieur ne sachant pas qu'il fait de la prose va se monter la mayo. Alors calm down les yamlhaters ; vous voulez juste réduire le multivers Marvel à la petite chambrette que vous connaissez et priver les autres de la richesse qui vous dépasse. Grandissons et cessons de comparer le ragout à la patate cuite ;p
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'aime le yaml
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 14 janvier 2023 à 10:42.
Ça peut devenir subtile comme frontière. Quand j'expose un contrat OpenAPI en http pour que ce soit manipulé ensuite par un générateur de code ou une gateway c'est de quel côté ?
Json est dans un paquet de bibliothèques standard là où yaml non ajouter une dépendance en plus ou avoir un peu moins bien ça se questionne.
Et json est un bon format d'échange quand tu veux être lisible par un humain sinon tu as tout un tas de format qui seront meilleur en temps de serialisation, taille serailisé ET temps de déserialisation.
Au final json est un format d'ubiquité beaucoup de langages l'ont dans leur bibliothèque standard, la majorité des éditeurs le manipulent correctement sans configuration préalable, il est simple, il est connu et largement utilisé, comme pi aller au problème de perf il se compresse pas trop mal (mais ça reste moins bon que des formats compact de base). C'est évident qu'il est utilisé partout et pour tout.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: J'aime le yaml
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
contrat en http & manipulé par un générateur de code ou une gateway
C'est bien du côté échange de données sérialisées par/pour machines
Bon, c'est de l'OPenAPI qui est la variante description de conf documentée par/pour les humains …de JSON-Schema. On a donc la possibilité de mettre des commentaires (dont les machines se contrefichent), d'utiliser des références et de la composition comme facilités (dont les machines entre elles n'ont que faire entre elles) etc.
Tout comme JSON, YAML ne m'a jamais fait défaut et souvent les deux sont en standard soit en dépendance (mais disponibles et matures comme bibliothèques) donc kif-kif pour moi.
On est d'accord que Luc BSON est meilleur, et il est de plus en plus pris en charge.
Après, je ne remets pas en cause le fait que les gens veulent se contenter d'un pis-aller mais les articles et billets qui se lancent dans des comparaisons qui n'ont pas lieu d'être pour forcer les autres à adopter leur point de vue qui n'est finalement que du dogmatisme et de la foi religieuse.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: J'aime le yaml
Posté par barmic 🦦 . Évalué à 2.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: J'aime le yaml
Posté par claudex . Évalué à 4.
J'aime bien le yaml, mais je trouve que c'est une critique valide, surtout qu'il y a des synonyme. Il faut savoir que mettre
none va pas avoir la même signification que"no"alors que ce ne n'est pas le cas avecnotet et"not"par exemple, alors qu'il existetrueetfalse(bon, je crois que ce cas a été corrigé dans les normes récentes mais c'est encore comme ça que ça fonctionne dans la plupart des parsers). Ce n'est pas du tout pratique pour un format très répandu. Surtout que quelqu'un qui ne connaît pas encore bien le format, il n'a pas encore bien configuré son éditeur de texte.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.