Trop de YAML

 (noyaml.com)
2 points par GN⁺ 2023-09-29 | 1 commentaires | Partager sur WhatsApp
  • YAML est utilisé comme un standard dans DevOps et les configurations de CI, mais à cause des conversions de type implicites et des différences entre parseurs, une même configuration peut être interprétée autrement que prévu
  • En YAML 1.1, des valeurs comme NO, 07, 08, 04:30, 0666 peuvent être transformées en booléens, nombres, heures ou octaux ; il faut donc expliciter clairement l’intention lorsqu’on veut une chaîne
  • Les exemples de GitHub Actions, Kubernetes, CloudFormation et de plusieurs services de CI montrent que la syntaxe YAML et les structures propres à chaque service peuvent conduire à des commits répétés, à des échappements imbriqués et à des représentations disparates des jobs
  • Les liens de référence regroupent aussi du YAML exécutable, les différences de comportement entre parseurs, la notation des chaînes multilignes, le problème d’une version 1.70 parsée comme 1.7, ainsi que les raisons de conception de StrictYAML
  • Des alternatives comme Nickel, Dhall, CUE et Jsonnet sont aussi proposées, mais la page elle-même ressemble à un immense champ de texte éditable, prolongeant la satire de l’utilisabilité de YAML

YAML comme langage de configuration DevOps : une satire

  • YAML est couramment utilisé pour les configurations DevOps, mais cette page exprime une fatigue liée à YAML avec des formulations du type « personne n’a envie d’utiliser YAML »
  • Elle énumère de façon paradoxale les raisons d’utiliser YAML comme technologie DevOps
    • Elle ironise en disant qu’il se compile toujours et peut toujours être déployé
    • Elle se moque du fait qu’il n’y ait pas de gestion forcée des erreurs pendant le développement et que les problèmes éclatent au runtime en production
    • Elle suggère qu’un message du type « quelque chose est cassé » vaut mieux qu’une stack trace avec numéros de ligne
    • Elle exprime l’agacement de devoir y passer du temps lorsqu’on crée un nouveau pipeline CI
    • Elle raille la situation où YAML est considéré comme un choix sûr simplement parce que Kubernetes l’utilise
    • Elle mentionne aussi son avantage par rapport à JSON : la prise en charge des commentaires

Les pièges des conversions de type implicites

  • En YAML 1.1, NO peut être parsé comme un type booléen
    • NO: Norway peut provoquer un problème d’interprétation booléenne plutôt que représenter un code pays
    • Si l’intention est une chaîne, il faut l’entourer de guillemets, comme "NO"
    • La page souligne que la spécification YAML 1.1 prévoit 22 façons d’écrire true ou false
  • Les valeurs qui ressemblent à des nombres peuvent aussi être interprétées différemment selon les parseurs
    • Les exemples 07 et 08 montrent que le résultat peut diverger, par exemple [ 7, "08" ]
    • La page en fait une satire avec un cluster Kubernetes qui se déploie jusqu’au septième élément puis échoue au huitième
  • Les chaînes qui ressemblent à des heures peuvent aussi être converties automatiquement
    • 04:30 peut devenir 16200, c’est-à-dire une valeur en secondes depuis minuit, plutôt que la chaîne horaire saisie par l’utilisateur
    • Si l’intention est une chaîne, il faut l’indiquer explicitement avec !!str 04:30
  • Les différences de notation octale en YAML ajoutent aussi à la confusion
    • YAML 1.1 utilise la notation 0666
    • YAML 1.2 utilise la notation 0o666
    • Le fait que Kubernetes utilise YAML 1.1 est présenté comme un « rite de passage DevOps »

Problèmes de versions, de SHA et de traitement des chaînes

  • Les versions de paquets peuvent être parsées comme des nombres à virgule flottante
    • foo: 1.7 et bar: 1.70 peuvent être interprétés comme la même version
    • fizz: 1.7.0 et buzz: 1.70.0 peuvent être traités comme des chaînes de version différentes
  • Les SHA Git courts utilisés en CI peuvent eux aussi ne pas être sûrs
    • Un SHA à 8 caractères peut être composé uniquement de chiffres
    • my.flaky_version, qui insère ${GIT_SHORT_SHA} sans guillemets, peut ne pas être une chaîne
    • La valeur est présentée comme étant une chaîne dans environ 98 % des cas, et comme une chaîne dans 100 % des cas si elle est entourée ainsi : "${GIT_SHORT_SHA}"
  • Un cas lié à la toolchain Rust est aussi inclus dans les liens de référence

Les coûts visibles dans la CI et la configuration d’infrastructure

  • Un exemple raconte qu’en apprenant GitHub Actions, une personne a fait 8 commits/pushs en une heure, avec comme dernier message de commit « I don't really like yml »
  • La page montre aussi à quoi ressemblerait SQL s’il était écrit en YAML
    • Des structures SQL comme SELECT, FROM, WHERE EXISTS, AND, EQUALS, LT deviennent des structures YAML imbriquées
    • Elle se moque de la transformation d’une expression SQL courte en une forme YAML longue et verbeuse
  • Chaque service de CI a sa propre manière de représenter les jobs et les steps
    • Azure DevOps utilise une forme avec jobs, puis job, steps, script
    • CircleCI utilise une forme avec jobs, job1, steps, checkout, run
    • L’exemple d’un « système de CI du futur » montre que la même tâche pourrait être représentée par encore une autre structure imbriquée
  • Dans CloudFormation, lorsqu’on place une fonction SEARCH dans DashboardBody de CloudWatch, un exemple montre qu’il faut ré-échappper du contenu déjà échappé et fermer tout le JSON avec des guillemets doubles

YAML exécutable et différences entre parseurs

Ressources liées et alternatives

Réactions à la page elle-même

  • La sélection de réactions Reddit prend aussi pour cible le design de la page
    • Certains disent que le site web est un immense champ de texte éditable
    • Certains disent que les hyperliens ne sont pas cliquables
    • Une blague dit qu’on peut sélectionner tout le texte de la page et le supprimer, ce qui résout le problème
    • Certains disent être d’accord avec la critique de YAML, tout en trouvant discutables les choix de design du site
  • La dernière phrase indique que la page a été délibérément rendue « aussi utilisable que YAML »

À lire aussi

1 commentaires

 
GN⁺ 2023-09-29
Avis de Hacker News

  • Mon casse-tête préféré, c’est celui-ci :
    07
    08
    Le résultat devient [ 7, "08" ]
    À cause d’une hypothèse sur les octaux et les chaînes de caractères.
    Cette hypothèse a été découverte dans du YAML généré par template trois niveaux plus bas, et a provoqué une panne complète de notre cluster k8s, mais seul le cluster 08 a cassé. Les sept premiers fonctionnaient bien.

    • Je suis la personne qui a créé ce site. J’aimerais bien que tu m’envoies ça en pull request.
    • Bon sang, j’imagine que la plupart des développeurs aujourd’hui ne connaissent pas les octaux ni les littéraux numériques octaux avec préfixe 0.
      Ce commentaire m’a fait rire, mais quand on pense qu’en 2023 presque personne n’utilise d’octaux dans des fichiers de configuration, ce comportement et cette hypothèse n’ont aucun sens. Pour de l’hexadécimal, pourquoi pas ; le décimal, évidemment ; mais l’octal, c’est un peu violent.
    • Je ne comprends pas comment ça pourrait être le comportement correct.
    • Quand tu dis que tu as « découvert » cette hypothèse, ça veut dire que tu n’avais pas lu la spécification et que tu as commencé en supposant connaître le comportement ?
      La partie qui a généré ça n’a clairement pas sérialisé les données avec une bibliothèque. Si elle l’avait fait, elle aurait converti les types dans le bon format.

  • YAML a beaucoup de problèmes, mais je pense que le vrai problème central, c’est de vouloir mettre de la logique dans la configuration.
    Si on utilise YAML uniquement pour les données et pas pour la logique, c’est l’un des formats de données les plus agréables à lire et à écrire par des humains.
    En CI/CD, il y a toujours une certaine dose de logique, et ça se termine rarement avec du YAML pur ; des templates bizarres viennent s’y ajouter. Je me demande pourquoi on ne fournit pas plutôt une vraie API pour un vrai langage de programmation.

    • Ce n’est pas tant un problème de YAML qu’une mauvaise utilisation de YAML. La complétude de Turing accidentelle est un problème partout.
      Il y a 15 ans, on avait le même problème avec Ant basé sur XML, et ce n’était pas la faute de XML.
      Le principal problème de YAML, à mon avis, c’est le manque de sûreté de typage : mauvaise indentation, fautes de frappe dans les clés, chaînes parsées comme des booléens, etc.
      À part ça, je trouve que c’est un bon format : concis, avec beaucoup moins de bruit syntaxique que d’autres formats. C’est pour cela que j’ai créé https://github.com/crdoconnor/strictyaml afin que les gens puissent utiliser du YAML typé de façon sûre et recevoir des messages d’erreur immédiats et clairs pour ce genre de problèmes.
    • D’après mon expérience, plus un langage peut faire de choses, plus les gens l’utilisent de manière complexe.
      Parce qu’ils introduisent des abstractions en pensant en avoir besoin. C’est pourquoi j’évite toujours d’utiliser un langage de programmation Turing-complet comme format de configuration.
      J’ai déjà passé des heures à suivre pas à pas de l’AWS CDK avec le débogueur JavaScript. Avec un simple fichier yaml/Json/peu importe, bête et méchant, ce problème n’aurait pas existé. C’était un petit projet, et cette complexité n’était pas nécessaire.
      C’est aussi pour ça que, pour la configuration des outils JS, je préfère JSON à JS. C’est l’une des raisons pour lesquelles les configurations webpack deviennent ingérables. Dès qu’on peut utiliser un vrai langage, le « capteur DRY » des gens se déclenche et ils rendent les choses plus complexes.
      En déclaratif, il est aussi plus facile de suivre les pratiques standard et le support des outils est meilleur. Si package.json devenait réellement comme build.gradle, ce serait bien pire.
    • Une configuration exécutable peut apporter de gros avantages. Python est un choix évident.
      Il suffit de décider : « exécuter le script dans un interpréteur Python placé dans un cgroup très restreint, et le résultat doit être un dictionnaire appelé CONFIG ». La logique d’enveloppe n’a plus qu’à le sérialiser de la manière la plus pratique pour le programme à configurer.
    • Je ne vois pas pourquoi une mauvaise conception de schéma serait la faute de YAML et non celle du concepteur du schéma.
      C’est un peu comme se plaindre de la complexité ou de la rigidité de helm. Les charts Helm ne s’écrivent pas tout seuls. Je suppose qu’il est plus facile de se plaindre et d’ignorer le problème que de le comprendre et de l’implémenter.
    • D’accord à 100 %. Quand les gens disent qu’ils détestent YAML, dans beaucoup de cas, je pense qu’ils veulent en réalité dire : « je déteste décrire des pipelines en YAML ». Je comprends ce sentiment.
      En tant que format de fichier, YAML a ses avantages et ses inconvénients. Mais le vrai problème, c’est de vouloir exprimer des conditions, des boucles, des fonctions, voire des classes/sous-classes via des templates, dans un format de fichier équivalent à JSON.
      YAML convient aux petites configurations. Mais dès qu’un flux de contrôle, quel qu’il soit, devient nécessaire, cela se transforme très vite en spaghetti propre à chaque fournisseur.

  • Jinja dans du YAML me semble clairement être un anti-pattern
    On dirait que cela vient du fait qu’on n’a pas conçu dès le départ une programmabilité suffisante, puis que les gens ont imité des projets qui ont réussi en choisissant cette voie par la suite
    L’article mentionne des alternatives comme Dhall et Jsonnet, mais on peut en envisager deux autres
    Premièrement, créer une bibliothèque de configuration pour un vrai langage de programmation, et faire en sorte que cette bibliothèque génère des fichiers de configuration JSON. Ce JSON ne serait pas destiné à être édité à la main, mais seulement traité comme un artefact vérifiable. L’utilisateur versionnerait une configuration sous forme de code avec prise en charge par les outils. Le fait que les corrections d’urgence directement sur le serveur deviennent plus difficiles est à la fois un inconvénient et un avantage
    Deuxièmement, Starlark. C’est un langage dérivé de Python, non Turing-complet, initialement développé pour le système de build Bazel. Il existe plusieurs implémentations et je ne sais pas jusqu’où va leur compatibilité, mais il y a aussi des bindings Python : https://github.com/caketop/python-starlark-go, https://github.com/inducer/starlark-pyo3

    • Je suis d’accord pour dire que Jinja dans du YAML est un anti-pattern, mais surtout parce que les caractères de bloc/expression par défaut {% et {{ sont tous deux des caractères YAML, ce qui oblige à mettre entre guillemets tous les endroits où on les utilise
      Les approches comme ${{ dans GitHub Actions, ou <%, <<, me semblent bien meilleures. Bien sûr, il y a le risque que <<: fasse partie de la syntaxe YAML, mais ce n’est pas du Jinja valide
      Si cela veut dire qu’il ne faut rien mettre d’exécutable dans du YAML, je pense que ce navire a déjà pris le large. Les gens ont compris que laisser les parties littérales par défaut et n’insérer de l’exécutable que de temps en temps était une bonne façon de produire du contenu, comme avec ASP/JSP/PHP
      Si vous voulez lancer une guerre de trolls sœur dans ce fil, il suffirait de parler de HCL et de for_each, mais mieux vaut sans doute éviter de le faire ici
    • C’est la voie qu’Amazon a choisie avec CDK. Ça fonctionne dans une certaine mesure, mais dès qu’on veut faire quelque chose de non trivial, on a fortement l’impression de construire une machine de Rube Goldberg
      Je ne sais pas quelle part relève de CDK et quelle part vient du fait que CloudFormation n’est pas terrible à la base
    • D’accord. Travailler avec du YAML templatisé était tellement pénible que j’ai fini par créer un outil pour ça, Cels : https://github.com/pacha/cels
      J’aime Jsonnet et Starlark, mais en pratique, la plupart des cas d’usage n’ont pas besoin d’un nouveau langage de programmation. En général, on veut simplement créer un document de base puis le modifier en appliquant des patchs. Tout devient alors beaucoup plus simple
      L’expérience d’utiliser du YAML pur n’est pas si mauvaise en soi. Le format a quelques aspects assez douteux, mais il est utilisable. À mon avis, le problème apparaît dans la complexité des solutions qu’il faut ajouter pour adapter les documents à plusieurs environnements
    • Rien que l’idée de devoir refaire de l’Ansible à cause de ça me donne des cauchemars
      J’ai entendu dire qu’il existait autrefois un vrai DSL Python utilisable à la place de YAML, mais il semble avoir été abandonné. Résultat, les boucles et les if-then deviennent maintenant d’horribles blocs interminables en YAML, et Jinja les interprète de façon totalement imprévisible
    • Je me demande s’il existe un outil autonome capable d’exécuter du code Starlark pour générer du JSON ou du YAML, comme jsonnet

  • À mon avis, YAML en soi est très bien. Ce qui ne l’est pas, c’est le fait que nous ayons rendu la partie déploiement du CD beaucoup trop difficile
    Je reconnais que notre configuration dans Azure DevOps n’est pas extraordinaire, mais je trouve étonnant qu’il existe des organisations où plusieurs équipes, ou 5 à 6 personnes côté ops, doivent manipuler ce genre d’outils. Pour des endroits comme Google, je ne sais pas, mais dans une entreprise ordinaire avec au maximum 50 000 utilisateurs simultanés, et généralement bien moins, ça me semble excessif
    Au début des années 2000, déployer une application web d’entreprise sur un IIS on-premise, où moins de 0,25 ETP gérait toutes sortes de choses comme la répartition de charge et le réseau, était plus facile que de déployer la même chose dans une configuration « moderne » actuelle
    Bien sûr, les pipelines modernes ont des avantages. On a beaucoup dépassé les problèmes du type « ça marche sur ma machine », et on a nettement amélioré le contrôle qualité grâce à de meilleurs points de validation. Mais le déploiement réel reste un cauchemar en 2023
    Ce n’est peut-être pas un problème pour les programmeurs de HN qui travaillent dans de vraies entreprises tech ou dans des sociétés disposant d’une bonne équipe DevOps dédiée. Mais dans le monde des entreprises non tech, le CI/CD n’a jamais été aussi mauvais dans ma carrière
    On peut accuser YAML, ou le fait qu’il faille beaucoup trop de YAML pour faire quoi que ce soit et que les templates soient difficiles. Mais à mon avis, c’est bien davantage un problème d’organisation qu’un problème technique. Les outils de CD devraient être beaucoup plus automatisés pour éviter que les développeurs aient à décrire l’infrastructure sous forme de code
    C’est bien que ce soit possible, mais la réalité, c’est qu’on demande à des millions de développeurs de déployer une infrastructure qu’ils comprennent peut-être à peine. Je n’ai jamais vu un développeur qui ne préférerait pas simplement fournir un conteneur et laisser le réseau et les « trucs côté serveur » se gérer tout seuls
    Si on ne fait pas ça, on se retrouve avec une quantité de VNET et de sous-réseaux dont personne ne comprend vraiment le fonctionnement, et l’organisation perd beaucoup d’argent parce que les développeurs ne savent pas qu’ils pourraient faire ça avec /x

    • Le cloud est le nouveau mainframe
      On écrit hors ligne une sorte de « définition de job » que l’on soumet à un système partagé propriétaire, on attend dans une file, puis on reçoit un fichier de logs généré par un système que l’on ne contrôle pas. Comme on ne peut pas exécuter localement sur sa station de travail le code du système propriétaire, la boucle d’itération interne prend au mieux des dizaines de minutes, et au pire des heures ou des jours
      Il n’y a pas de mode aperçu ou « what if », ni de « dry run ». Même si on appelle ça un « test », comme il n’y a qu’un seul système, on travaille en pratique en production
      Le vrai problème n’est pas YAML. Peu importe si le pipeline était scripté dans le langage de programmation de Dieu
      Si le développement logiciel sur station de travail est devenu si populaire par rapport aux mainframes centraux en temps partagé, c’est parce qu’il accélérait spectaculairement les itérations internes, isolait de l’environnement de production et remettait le contrôle entre les mains des développeurs
      La génération actuelle de pipelines CI/CD annule en grande partie tout cela
      Kubernetes sur une seule machine permet de retrouver l’essentiel des avantages du développement sur station de travail, mais c’est encore un système très récent, avec beaucoup de douleurs de croissance
      Problème connexe : il existe d’excellentes solutions pour un développeur seul qui exploite une application en cliquant dans une interface, et d’excellentes solutions pour les très grandes entreprises qui automatisent à grande échelle pour des milliers de développeurs. Mais entre les deux, dans la zone où quelques développeurs d’entreprise gèrent des dizaines d’applications, c’est juste le chaos
    • Je ne sais pas si on a complètement dépassé le « ça marche sur ma machine »
      Il m’est arrivé plusieurs fois que ça fonctionne très bien dans mon image Docker, mais que ça casse dans l’image déployée
      Ce sont des problèmes qu’on ne peut résoudre que si l’ensemble du pipeline de build et de déploiement est totalement transparent, qu’on a un accès complet au registre d’images et qu’on peut réellement contrôler les instructions de build. C’est aussi contraignant que de contrôler le système d’exploitation local, et je pense que ça échouera dans autant d’organisations que celles où le code cassait quand on le déplaçait vers une autre machine
    • Je ne vois pas ce qui pose problème dans le déploiement. Dans les configurations que j’ai faites, il suffisait d’ajouter un tag à un commit et de le pousser pour que ce commit soit déployé
      Configurer ça dans n’importe quel système CI/CD me semble assez intuitif

  • Je pense qu’il existe une solution pour préserver la paix si tout le monde respecte universellement une seule règle : n’utilisons pas YAML en dehors de l’écosystème Python
    Ainsi, les personnes qui aiment les formats de scripting ésotériques privilégiant la lisibilité à l’exactitude, à la robustesse et à la maintenabilité pourront continuer à utiliser les tabulations, le typage lâche et une syntaxe obscure. Les autres n’auront plus à le faire. Les personnes qui préfèrent les syntaxes de style C pourront garder leur santé mentale
    Je crois qu’on touche enfin au cœur du problème. Pour moi, développeur habitué aux syntaxes C, les espaces syntaxiques relèvent de la pure folie. Les espaces sont de la mise en forme, pas de l’information ni des instructions. Une bonne mise en forme aide et est utile, et un bon développeur en syntaxe C se soucie aussi d’une mise en forme lisible
    En Python et en YAML, la mise en forme est une information directive. Cela a l’avantage de rendre lisible tout code qui fonctionne. Mais pourquoi le code devrait-il nécessairement être lisible pour fonctionner ?
    Il suffit d’imaginer travailler avec un collègue qui serait comme YAML. Vous lui envoyez un long message, et il répond : « Quoi ? Ça n’a aucun sens ». En fait, le sens a été cassé parce que vous n’aviez pas mis de lignes vides entre les paragraphes. Vous remettez les lignes vides et renvoyez le message, et là seulement il peut le lire. Sans mise en forme syntaxiquement correcte, l’information envoyée n’avait aucun sens

    • Un autre objectif du code en tant que logiciel, au-delà du fait d’être exécutable, est d’être lisible
      Il existe d’innombrables façons de formater le code, et je préfère que les gens utilisent un linter quand ils écrivent du code. Si possible, le même linter que moi
      Ces langages imposent des structures syntaxiques standard. Cela réduit les façons d’écrire du code difficile à lire, et c’est une bonne chose
    • On considère généralement les espaces significatifs comme une question philosophique ou religieuse. Certains aiment, d’autres détestent, et les deux camps rationalisent leurs préférences, mais au final ce serait surtout une affaire de goûts très marqués
      Mais j’en viens à penser que la différence n’est pas philosophique, qu’elle relève plutôt des outils. Certains outils, par exemple les éditeurs de texte ou les clients e-mail, prennent bien en charge les espaces significatifs, et d’autres non
      Tous les éditeurs de texte que j’utilise sont configurés pour afficher les espaces et les tabulations, et les montrent différemment. En général, comme des points discrets et des tirets discrets. J’y suis habitué, ça ne me dérange pas du tout
      De mon point de vue, le code n’est pas du texte arbitraire. On utilise une police à chasse fixe qu’on n’emploierait pas dans un livre, et la syntaxe est distinguée par des couleurs. Il n’y a pas non plus de raison de ne pas rendre les espaces visibles
      Je continue à préférer les langages sans espaces significatifs, mais je ne les déteste pas. Pour moi, ce n’est pas du tout un problème
      En revanche, si vos outils préférés ne prennent pas bien en charge les espaces significatifs, ne rendent pas les espaces visibles, voire si vous codez avec une police à chasse variable, alors vous ne pouvez que haïr passionnément les espaces significatifs et les voir comme de la pure folie
    • Venant du C, je pensais moi aussi que les espaces n’étaient ni de l’information ni des instructions. Aux débuts de Python, je le regardais même un peu de haut pour cette raison
      Ce qui m’a fait changer d’avis, assez étonnamment, c’est CoffeeScript. Je n’aime pas beaucoup JavaScript, mais utiliser CoffeeScript donnait l’impression d’une version épurée de The Good Parts de Crockford. Il était impossible de produire accidentellement les mauvaises parties
      En plus, la façon dont l’indentation devient du code était plutôt agréable. Le seul inconvénient était qu’avec Vi, on ne pouvait pas appuyer sur % sur une accolade ouvrante ou fermante pour trouver l’autre extrémité du bloc. À l’inverse, grâce à l’indentation, quand le code avait l’air bizarre, il l’était souvent réellement
      Cela dit, je n’ai toujours pas beaucoup appris Python. Aujourd’hui j’utilise TypeScript, mais si un jour CoffeeTypeScript sortait…
    • C’est un peu étrange que TOML soit dans la bibliothèque standard et pas YAML. Et TOML est moche
    • La communauté Kubernetes observe ça avec un regard intéressé

  • C’est pour ça que j’ai commencé à créer moi-même un format appelé BCL : https://github.com/wkhere/bcl
    Ça n’aidera pas immédiatement tous les cas d’usage de YAML, mais au moins ça peut devenir une meilleure façon de définir des ressources dans un style à la Terraform. En fait, ça aide déjà dans un projet interne comme remplaçant de HCL, et c’est ce qui m’a finalement motivé à le créer
    Plus largement, je ne sais pas comment régler le problème de l’omniprésence de YAML dans Kubernetes. Plus de la moitié de mon problème avec mon $daily_job vient du fait que l’assemblage du chart Helm final à partir de plusieurs sources est beaucoup trop bricolé
    Je ne veux pas dire que Helm est intrinsèquement un mauvais outil, ni que mon entreprise a choisi Helm d’une façon particulièrement mauvaise. Je pense que tout le monde fait de son mieux compte tenu du contexte
    Mais manipuler des templates texte avec des espaces significatifs est beaucoup trop propice aux erreurs, et celles-ci sont détectées beaucoup trop tard. Kubernetes aurait été bien mieux avec un format personnalisé fondé sur une syntaxe de style C, plutôt que d’essayer de prouver à quel point YAML est formidable. D’autant que YAML n’est même pas formidable

  • C’est un effet de plateforme interne. À mesure qu’une application grossit, sa configuration s’étend elle aussi jusqu’à devenir un langage de programmation, mais un langage truffé de bugs, mal spécifié et à l’ergonomie épouvantable
    On déclare la faillite de la configuration et on choisit un nouveau format de configuration. Puis ça recommence
    Bien sûr, le format lui-même n’est pas totalement innocent. Plus il est flexible, plus il est facile de le recycler en mauvais langage de programmation
    Après avoir répété cette erreur plusieurs fois, aujourd’hui je choisirais le format de configuration le plus simple possible pour les réglages de base. Même .ini peut être trop puissant. Pour la « configuration » plus complexe, je déléguerais à un vrai langage de programmation, si possible celui dans lequel l’application est écrite

  • L’écrasante majorité des exemples du type « YAML, ce n’est pas terrible » se résolvent en mettant entre guillemets tous les littéraux bizarres
    Oui, YAML peut parfois être pénible. Par exemple, les listes de maps deviennent vite étranges, et les espaces significatifs finissent presque toujours par vous jouer un mauvais tour. Mais ces articles donnent, au mieux, une impression d’un certain manque de rigueur

    • Pourtant, aucun de ces exemples n’utilise de guillemets, et les outils ne le font pas non plus
      Tout l’écosystème YAML pousse à écrire les valeurs sans guillemets. La plupart du temps, ça marche bien, puis ça casse juste assez souvent pour vous faire trébucher en production

  • EDN est un sous-ensemble de Clojure : https://github.com/edn-format/edn
    C’est clair, utilisable en streaming, extensible et insensible aux espaces. Il existe toutefois des conventions de mise en forme pour la lisibilité

    • C’est la première fois que je vois un format de données qui distingue explicitement listes et ensembles, et c’est une bonne chose
      En revanche, je ne vois pas bien quelle est la différence sémantique entre une liste et un vecteur. Dans mon esprit, les tableaux et les listes chaînées sont des détails d’implémentation de structures de données dans le code, pas des différences de format de données
    • C’est bien meilleur que les alternatives. J’espère vraiment qu’il commencera à être utilisé en dehors de l’écosystème Clojure
    • À strictement parler, il est difficile de dire qu’il ne dépend pas des espaces, puisqu’il en faut pour les limites ou la séparation des éléments
      Mais il n’y a absolument aucun jeu d’indentation sémantique. Le fait que les virgules soient considérées comme des espaces et soient inutiles est élégant

  • Quand les étudiants rendent leurs devoirs via la plateforme d’e-learning, nous recevons toutes les soumissions dans un fichier XML assez volumineux
    Nous lisons les soumissions, les transmettons à l’analyse statique et à l’exécution d’exemples, puis nous écrivons, pour chaque devoir, un fichier YAML contenant toutes les soumissions, les indications de correction, les commentaires et les champs de saisie des notes
    Ensuite, à partir du fichier YAML, nous générons des rapports, des statistiques et des PDF de feedback en passant par markdown+lecture (Pandoc)
    Pour nous, YAML convient très bien. Il est facile d’ajouter du feedback avec la syntaxe Markdown. Par exemple, quelque chose comme - you missed a \NOT` here`, correctement indenté
    Grâce aux différentes façons d’échapper le texte en bloc, on peut afficher joliment les soumissions SQL sans caractères d’échappement, même si les étudiants utilisent divers délimiteurs SQL
    Comme tout est en texte brut, nous n’utilisons qu’un éditeur de texte, et nous stockons le tout dans git pour assurer la responsabilité de la correction. Comme tout est conservé sous une forme lisible par machine, nous pouvons aussi tester de nouveaux outils d’analyse statique sur d’anciennes soumissions
    Mais comme il faut aussi écrire les pipelines CI et la configuration de domotique en YAML, je comprends la douleur

    • La suppression de l’indentation du texte intégré est probablement la meilleure fonctionnalité de YAML
      Dans TOML, il faut soit renoncer à l’indentation des chaînes multilignes, au détriment de la lisibilité, soit mettre une barre oblique inverse à la fin de chaque ligne. Aucune des deux solutions n’est idéale
      C’est pourquoi YAML est assez adapté aux DSL ou aux configurations qui doivent contenir du Markdown ou d’autres formats texte, et il a un avantage sur des formats comme TOML
      Mais je ne mettrais pas toute la responsabilité de la « fatigue YAML » uniquement sur les outils de CI et de DevOps qui ont choisi YAML comme format de transport pour leurs DSL. Comme l’article original le résume bien, YAML lui-même a aussi de gros problèmes
      Le célèbre « problème de la Norvège » a été résolu dans YAML 1.2, et le problème du parsing des zéros initiaux comme nombres octaux l’a également été dans YAML 1.2. Les conversions de type trop agressives pour les nombres, les dates, les heures, etc., peuvent prêter à confusion. Les modes de traitement des chaînes multilignes peuvent aussi être assez déroutants. La sérialisation non sécurisée n’est pas un problème avec les parseurs modernes, mais il faut rester prudent quand on utilise YAML dans d’anciens langages dotés de fonctionnalités dynamiques comme Ruby, Python ou Java
      Tout cela relève de problèmes propres à la spécification YAML