JSON, YAML, TOML, XML,... Ou comment se compliquer la vie

En fait, je vois deux situations :

1. Un humain est censé lire et modifier le fichier, et là, en effet la question d’utiliser un format textuel simple est importante.
2. Aucun humain n’est censé lire et modifier le fichier, et là on s’en fout complètement de savoir si le fichier est lisible ou non. Le choix doit donc se faire sur des critères techniques.

Or, le cas n°2 est beaucoup, beaucoup plus fréquent. Et le JSON, le YAML, le XML et d’autres ont des avantages techniques majeurs :

• Ils sont normalisés : quelque soit le langage de programmation utilisé, un fichier bien formé sera correctement lu si un parseur non buggé est disponible.
• Ils sont structurés¹, et donc permettent donc un mapping direct avec des structures techniques.
• JSON et XML ont des parseurs extrêmement performants dans à peu près tous les langages imaginables.
• JSON a des parseurs natifs et efficace pour les applications web et mobile (mais pas XML²).
• XML, avec un parseur bien conçu (donc pas tous), peut être lu et traité sans avoir à monter tout le fichier ou toute sa représentation en mémoire.
• XML arrive avec tout un ecosystème qui peut être bien pratique selon ce qu’on veut faire (XSLT, XPath, validation…).
• Et sans doute plein d’autres trucs auxquels je ne pense pas.

J’ajoute enfin que ce n’est pas parce qu’un format est simple qu’il est facile et efficace à parser. Le plus bel exemple pour ça est CSV : ça a l’air tellement simple qu’on est tenté de le parser « à la main » (sans utiliser de bibliothèque dédiée). Jusqu’au moment où on découvre que 1. le format n’est pas normalisé correctement (rien que le séparateur ,, ou ; si de fichier est issu d’un Excel français) et 2. dès que les champs contiennent des " ou des sauts de ligne (oui, c’est possible, et si vous lisez le fichier ligne par ligne, sans traitement spécifique vous êtes mort), ça devient galère.

Salut,

Mes exemples se basent effectivement sur des cas où un utilisateur est amené à modifier le fichier à la main (même si c’est plus discutable pour le manifest.json, une intervention manuelle peut être requise) et où la lisibilité et la simplicité du format est dès lors importante. Toutefois, à supposer même que le fichier ne soit pas amené à être modifié à la main, le choix d’un format simple reste de mon point de vue important.

La normalisation du langage est surtout importante dans le cas où il y a un souci d’interopérabilité important (à nouveau, le cas du XHTML est probablement le plus emblématique puisque ce dernier doit pouvoir être interprété de la même manière par tous les navigateurs, entre autres). Or, c’est rarement le cas pour pas mal de logiciels, les trois exemples que je donne ici ne sont pas concernés par une telle problématique.

Le format INI ne prévoit effectivement pas par défaut de hiérarchie entre les sections, je l’ai donc un peu amendé pour que cela soit le cas. Cela étant dit, je l’ai choisi pour l’exemple, d’autres solutions sont possibles.

De ce côté, vu leur usage massif, j’espère bien qu’ils ont des parsers performants.
Cela étant, que ces formats complexes disposent ou non de parsers performants, le parsing d’un format simple sera toujours moins gourmand en ressources (sauf s’il est codé avec les pieds, mais c’est pas la question).

Mon propos dans ce billet est avant tout de dénoncer l’emploi de formats complexes comme fichiers de configuration ou de stockage de données alors que le plus souvent cela n’est pas nécessaire et inutilement complexe. Le choix d’un langage normalisé ne doit à mon sens se faire que si le programme se doit d’être interopérable. Si ce n’est pas le cas, alors ce sont pour moi ces deux points qui doivent être réunis :

1. Si l’utilisateur doit le modifier, qu’il puisse le faire sans se prendre la tête ;
2. Le parsing doit être simple et efficace.

Mon propos dans ce billet est avant tout de dénoncer l’emploi de formats complexes comme fichiers de configuration ou de stockage de données alors que le plus souvent cela n’est pas nécessaire et inutilement complexe.

alors petite expérience personnelle:

Au boulot on a une plateforme "legacy" qui est en java et on utilise au besoin soit le format de base de java soit le format ini pour faire les configurations.

En face on a les "nouveaux" programmes qui sont en go et qui utilisent toml pour les confs statics et json+s3 (pour le stockage) pour les configuration qui sont éditable par les clients.

Pour les confs statiques voici ce que le toml nous a apporté :

• pouvoir intégrer très facilement la configuration d’un objet issu d’une lib : comme le format est structuré hiérarchiquement il suffit de dire "dans ma conf principale j’ai une section qui correspond aux paramètres de la lib" et ça marche
• pour valider les types aussi c’est 10 fois moins verbeux : si tu fais pas gaffe tu fais tout le temps des fautes de frappe qui changent le type et un format structuré fait que tu n’as pas à faire la vérif à la main : la désérialisation va fail et tu vas pouvoir corriger rapidement

D’ailleurs c’est encore plus intéressant avec json car on peut ajouter des schemas json qui nous permettent de faire des validations encore plus poussées, un peu comme pour le xml d’ailleurs.

Au début j’étais comme toi : du xml pour confiugrer c’est relou, du json pour stocker c’est imbittable. Et puis je suis arrivé dans le "monde réel" (trade mark, copyrighté jusqu’en 9999 etc etc.) où il y a des bugs dans les données d’entrées, des erreurs humaines, disques réseau qui lâchent en pleine écriture et avoir un moyen de repérer des erreurs, parfois de les corriger, souvent de rollback facilement est devenu une nécessité que les fichiers ini n’ont pas. Et pour avoir eu un pb bien grave sur les confs statiques qu’on a réparé à la main en urgence je peux te dire que ça nous a bien fait chier quand le paramètre de conf qui pilote une tâche qui a lieu tous les deux jours a fait foirer ladite tâche 36h après la remise en route, va-t-en savoir ce qui bug quand c’est comme ça.

Personnellement j’utilise le XML au boulot car il a des avantages que les autres formats n’ont pas (dont l’INI, que j’aime pourtant bien aussi) :

• On peut avec un fichier XSD à côté s’assurer que le fichier d’entrée est correcte et ne possède pas de cas bizarres qui n’a pas été prévus. Idéal pour un système dont l’entrée est fondamental pour ne pas charger une connerie (et donc faire n’importe quoi avec).
• C’est très facile de vérifier si le XML est à priori entier ou pas. Juste en vérifiant si la balise mère a été fermée à la fin, on peut être sûr que l’enregistrement a été fait entièrement (je travaille en embarqués, si l’alimentation coupe pendant l’enregistrement d’un fichier, c’est bien de le voir très vite).
• Le XML est verbeux mais la syntaxe de base (donc pas de namespace par exemple) est simple sans avoir besoin trop d’XP. Un technicien qui n’en a jamais vu peut rapidement modifier ou remplir un fichier XML avec quelques indications, le JSON et YALM demandent selon moi plus d’efforts (car moins verbeux et moins intuitifs).
• Le XML permet différents moyens d’être parsés, tous avec leurs avantages et inconvénients (en terme de ressources nécessaires, ou de complexité de code derrière) : XPath, DOM ou séquentiel. C’est une belle souplesse.

Le format INI ne prévoit effectivement pas par défaut de hiérarchie entre les sections, je l’ai donc un peu amendé pour que cela soit le cas. Cela étant dit, je l’ai choisi pour l’exemple, d’autres solutions sont possibles.

Du coup, t’as juste recréé TOML, le typage en moins. Si il y a une telle pléthore de format texte, c’est bien parce qu’il y a des besoins variables. INI est une vraie plaie à parser parce qu’outre l’absence de standard, il n’y a aucun typage des données. Si tu as un champ bidule=12, c’est la chaîne "12" ou bien le nombre 12 ? Du coup, pour les fichiers de config minimaux à destination des humains, j’aime bien TOML. La syntaxe pour les sous sections est un peu lourde, mais sur une structure qui reste simple avec peu de niveaux, ça le fait bien.

Vraie question ici (et idem pour la suivante) : ce n’est pas dupliquer le boulot de procéder de la sorte en plus d’augmenter le risque d’erreur ? Je veux dire, finalement tu dois parser un fichier XSD et un fichier XML, en ayant à chaque fois un risque d’entrées invalides et/ou d’erreur de parsing.

Le résultat ne serait pas le même en ajoutant par exemple une section finale oligatoire ?

1
2

[End]
STATUS=SUCCESS

Tu veux dire un mapping plus ou moins direct entre une structure de données et le format textuel, genre comme ceci ?

1
2
3
4

struct array {
        size_t size;
        int data[*];
};

1
2
3

array:
  - size: 6
  - data: [ 0, 1, 2, 3, 4, 5 ]

Mmm… Est-ce que tu peux détailler ce point s’il te plaît ? En quoi la validation des types est-elle moins verbeuse en JSON ou YAML par exemple ?

Même vraie question qu’à Renault ici : ce n’est pas dupliquer le boulot que d’employer un fichier de schéma et un fichier de données sachant que les deux doivent être analysés et validés ?

Je t’avoue que je n’ai pas suivi ce passage. ^^"

Heu… Le TOML est quand même nettement plus évolué que ça. ^^"
Par ailleurs, ce que j’emploie reste de l’INI, j’emploie juste une extension pour désigner des sous-sections, ce qui est parfois employé avec ce format sauf que cela prend plutôt la forme [A.B.C] ou [A\B\C]. Enfin, comme je l’ai dit, j’ai pris l’INI en exemple parce qu’il est connu, mais d’autres choix sont parfaitement possibles.

A priori, c’est à toi de le déterminer et de vérifier tes entrées en conséquence.

Tu veux dire un mapping plus ou moins direct entre une structure de données et le format textuel, genre comme ceci ?

c’est ça;

Mmm… Est-ce que tu peux détailler ce point s’il te plaît ? En quoi la validation des types est-elle moins verbeuse en JSON ou YAML par exemple ?

Tout dépendra du langage ou de la lib (typiquement tu as pas de validation de type en python) mais si tu tentes de désérialiser un JSON pour le mapper dans un objet bien typé, l’immense majorité des libs t’enverra une erreur en te disant quel field est mauvais.

Avec un simple ini, il faut faire soit même les checks (donc une ligne par field). En plus comme il y a un typage faible "32" est sensé être identique à 32 et donc même avec une bonne lib tu auras des pbs in fine car les conversions c’est pas une science exacte.

Je t’avoue que je n’ai pas suivi ce passage. ^^"

pour faire simple

• avec une donnée structurée, on découvre rapidement les erreurs (humaines, logicielles, materielles)
• avec une donnée structurée, tu peux corriger l’erreur d’une manière bien plus robuste que les sempiternelles "valeur par défaut"

Vraie question ici (et idem pour la suivante) : ce n’est pas dupliquer le boulot de procéder de la sorte en plus d’augmenter le risque d’erreur ? Je veux dire, finalement tu dois parser un fichier XSD et un fichier XML, en ayant à chaque fois un risque d’entrées invalides et/ou d’erreur de parsing.

je dirais que non : le schéma de validation est packageable, et testable unitairement, tu auras donc la possibilité d’être certain de son fonctionnement. Le fichier de conf, lui, il est ouvert à tout le monde. l’utilisateur est sensé le modifier alors que le fichier de validation ne doit pas être touché, c’est un fichier de dev.

Vraie question ici (et idem pour la suivante) : ce n’est pas dupliquer le boulot de procéder de la sorte en plus d’augmenter le risque d’erreur ? Je veux dire, finalement tu dois parser un fichier XSD et un fichier XML, en ayant à chaque fois un risque d’entrées invalides et/ou d’erreur de parsing.

Pour moi, c’est exactement comme dire qu’un test duplique le boulot.

C’est vrai dans l’exécution, mais en pratique ça réduit les problèmes et les rend compréhensible et éventuellement tracable.

Vraie question ici (et idem pour la suivante) : ce n’est pas dupliquer le boulot de procéder de la sorte en plus d’augmenter le risque d’erreur ? Je veux dire, finalement tu dois parser un fichier XSD et un fichier XML, en ayant à chaque fois un risque d’entrées invalides et/ou d’erreur de parsing.

En général le parsing (surtout du XSD) est généré de bout en bout par une bibliothèque. Le risque d’erreurs est faible. L’intérêt du XSD est qu’il est en général écrit une fois lors de la conception du programme. Le XML peut changer par le problème lui même (s’il doit sauvegarder des données) ou par l’utilisateur s’il doit configurer un truc. Le fichier XML est donc peu fiable en terme de validité contrairement au XSD qui est normalement écrit et testé une fois pour toute. Cela apporte une garantie assez forte que le fichier XML en entrée ne sera utilisée que s’il est valide car l’erreur peut arriver très facilement en cas d’écriture qui merde (coupure de courant au mauvais moment) ou un utilisateur qui n’a pas fait gaffe.

Le résultat ne serait pas le même en ajoutant par exemple une section finale oligatoire ?

On pourrait mais ce n’est pas une méthode standard non plus et l’absence de format de validation est un problème. Car il est intéressant d’avoir la garantie que le champs config/hardware/name contienne un nom valide (donc Produit 1, 2 ou 3 mais pas 4 ou 5 qui n’existent pas forcément) ou que le champs config/harwarde/temp/range/min soit forcément plus petit que l’équivalent max et que la plage de valeur pertinente c’est entre 150 et 250.

Bien sûr, avec un ini tu peux le faire, mais c’est manuel, avec risque d’erreur, et si cela change demain tu dois changer le programme et le recompiler (et refaire des tests) alors qu’avec le XSD tu gagnes beaucoup de temps avec des garanties de fonctionnement fortes.

Et l’avantage du XML est que si demain le langage du projet change pour X ou Y raisons, l’adaptation sera rapide. Si tu as tout fait à la main, tu dois tout refaire aussi. D’ailleurs sur mon projet actuel le périphérique et un serveur doivent synchroniser le fichier de configuration du périphérique. Avec le même XSD nous pouvons vérifier des deux côtés que le fichier est correct. Et si changement il y a à faire dedans, changer le XSD commun est suffisant. Avec ton fichier INI il faudrait changer beaucoup plus de code des deux côtés avec risque d’erreurs à la clé.

Je n’ai rien contre le format INI, que j’affectionne pour nombres d’usages, mais le XML ou JSON ont leur intérêt et des cas d’usages aussi. Il n’y a rien d’universellement parfait. Le tout est de choisir convenablement en fonction de ses besoins.

A priori, c’est à toi de le déterminer et de vérifier tes entrées en conséquence.

C’est… exactement le problème que je soulève. Tu peux pas écrire un parser de fichier INI sans savoir par quoi il va être consommé. Inversement, tu ne peux pas te reposer sur un parser existant quand tu écris ton code. Et enfin, pour l’UX c’est pas terrible si t’es obligé de vérifier dans la doc le type des entrées.

Merci pour vos précisions.

Je vois donc l’idée du XSD et des schémas en général : déléguer la vérification des données à une bibliothèque dédiées, en partant du principe qu’il y a peu de risque d’erreurs (en tous les cas moins que dans les autres cas) le schéma étant rédigé durant le développement et la bibliothèque tierce maintenue par une équipe (normalement) compétente.

Ah ! Ok, au temps pour moi. ^^"

J’arrive vraiment après la bataille. Mais je constate que Taurre à raison sur énormément de points.

• JSON est pratique mais illisible pour un humain en plus d’être dur à modifier à la main.
• XML vieux et toujours pas pris en charge complètement dans la plupart des langages, c’est inutilisable, ni à la main ni avec un programme. Les bibliothèques qui supportent bien le format XML sont soit lentes soit complexes.
• YAML, dans l’idée c’est pas mal, dans les faits c’est mal spécifié et sa complexité est certainement nécessaire pour la sérialisation mais inutile dans la plupart des cas.
• TOML j’aime bien mais seulement s’il apporte un vrai plus par rapport à l’INI.

Bref, vive l’INI.

XML vieux et toujours pas pris en charge complètement dans la plupart des langages, c’est inutilisable, ni à la main ni avec un programme. Les bibliothèques qui supportent bien le format XML sont soit lentes soit complexes.

Bof avec ce constat.

XML n’offre pas le meilleur ratio octets / info utiles et je ne crois pas que les bibliothèques à ce sujet soient rapides. Mais ils font le job et pour la majorité des cas où la taille des fichiers est faible, cela est largement satisfaisant.

C’est le constat que j’ai fais en cherchant une bibliothèque XML supportant les namespaces XML. J’ai trouvé libxml2, la bibliothèque standard python et Javascript.

Rust et Go par exemple sont dépourvus de bibliothèque correcte pour gérer XML.

Heureux de lire (même après un an ), que mon point de vue est partagé par d’autres personnes.

Comme je le disais en conclusion, le but de l’article n’était pas tellement de faire une ode au format INI, mais d’inciter à réfléchir quant au choix du format de fichier qui, trop souvent à mes yeux, se résume à « il y a une bilbiothèque qui fait la taf, alors je prends ce format ». En soit, cela peut parfaitement se justifier (ces formats complexes sont nés d’un besoin réel), mais de ce que j’en vois, le plus souvent, ils sont choisis par défaut et/ou pour éviter d’avoir à écrire un petit analyseur syntaxique (qui se résume à pas grand chose pour un format simple).

Bonjour, J’ai bondi de ma chaise en lisant ce billet et les commentaires.

Les bénéfices des "langages" XML et Json au moins me semblent tellement évidents, que je ne comprends pas du tout qu’un tel billet ait pu être écrit et qu’autant de monde soit d’accord sur sa conclusion.

En vrac, ces formats fournissent les avantages suivants : une structuration hiérarchique hyper extensible et facile à comprendre (et vite illisible avec un .ini), des formats de données standardisés (valeurs numériques et dates, notamment), des outils standardisés de sérialisation / dé-sérialisation en objets (en tout cas en C#, et je n’ose pas imaginer qu’on n’ait pas les mêmes outils en java), des formats connus des moteurs de base de données (MySQL, Oracle, SQL Server…). Alors, oui, on peut s’amuser à chaque projet à réécrire son analyseur syntaxique, mais franchement, je n’y vois aucun bénéfice :

• votre code sera-t-il vraiment plus efficace qu’un analyseur XML ? Et si cela ne porte que sur quelques centaines de lignes de configuration, combien de millisecondes aurez vous (éventuellement…) gagnées ?
• Et vous trouvez vraiment les exemples .ini décrits dans le billet plus faciles à lire que les format XML ou json ? Désolé, mais pas moi: c’est très compliqué avec un .ini de comprendre la structuration des données et leurs dépendances (cf 3e exemple).
• Et quid de la gestion des caractères spéciaux (sauts de lignes, etc), pas du tout standardisés en .ini ? Charge à vous de passer du temps à concevoir une solution et à l’implémenter.

Bref, je pense que l’auteur fait complètement fausse route…

Les bénéfices des "langages" XML et Json au moins me semblent tellement évidents

Je te rejoins tout à fait.

En vrac, ces formats fournissent les avantages suivants : une structuration hiérarchique hyper extensible et facile à comprendre (et vite illisible avec un .ini)

Ini n’a que des sections. Juste des sections y a pas de hiérarchie. La hiérarchie d’un fichier ini ne peut pas être illisible.

des formats de données standardisés

Ça, c’est vraiment vachement cool.

des outils standardisés de sérialisation / dé-sérialisation en objets (en tout cas en C#, et je n’ose pas imaginer qu’on n’ait pas les mêmes outils en java)

Il n’y a que moi qui pense que la sérialisation dans des formats de textes, c’est une erreur ? Je comprends comment ça a pu arriver, mais je le déplore vraiment.

Alors, oui, on peut s’amuser à chaque projet à réécrire son analyseur syntaxique, mais franchement

Il existe des bibliothèques pour lire du INI dans tous les langages.

Je ne pense pas.

XML, l’avantage, c’est qu’il est hiérarchique et qu’il peut être validé par un schéma. Son inconvénient, c’est qu’il est complexe. Donc souvent lent et que généralement, il n’a qu’un support partiel. XML Validation, XML Namespace et j’ai pris Python, c’est pas le pire langage niveau réputation.

JSON son avantage est qu’il est super bien intégré au Web. C’est un format d’échange. À l’époque depuis le Web, il n’y avait que HTTP, qui ne propose pas d’échanger des données binaires. D’où l’utilisation de XMLHTTPRequest. Qu’on utilise toujours alors même qu’on utilise plus XML derrière. On a remplacé le XML par JSON car justement, JSON est rapide à parser et plus léger.

Le propos de @Taurre n’est pas que JSON, XML et autres sont des trucs inutiles. Le propos c’est qu’ils sont inutilement utilisés dans des cas où INI serait utilisé efficacement.

Salut,

Comme l’a souligné @ache, ce billet et sa conclusion ne vise pas à remettre en cause ou critiquer l’existence de ces formats, mais leur utilisation « abusive » ou « par défaut » dans quasiment tout nouveau projet informatique alors que cela n’a pas forcément de sens ou d’intérêt. Par ailleurs et une fois encore : ce billet n’est pas un plaidoyer en faveur du format INI (ce n’est pas à défaut de l’avoir écrit noir sur blanc dans la conclusion…).

J’ai choisi le format INI pour illustrer mes exemples parce qu’il est simple et connu d’un peu près tout le monde, mais le message de fond du billet est : « cherchez la simplicité lorsque vous choisissez comment stocker des données dans un fichier, pas la facilité ».

Si le projet ne nécessite pas un format complexe, sans aucun doute, et ce probablement même s’il est écrit avec le derrière (l’analyseur syntaxique). Maintenant, le but n’est pas spécifiquement de gagner en performance, mais en simplicité : on supprime une dépendance à une ou des bibliothèques et on obtient un format plus lisible et aisé à analyser.

Question de goûts. De mon côté, oui, je trouve les exemples INI plus facile à lire et à comprendre.

Si le prix est une plus grande simplicité, je ne vois pas d’inconvénient à créer son propre format du moment que l’effort demandé n’est pas trop conséquent (autrement dit, si le format se rapproche d’un XML bis, ce n’est sûrement pas la bonne voie).

Je tombe sur ce billet et… mon dieu…

Je ne sais pas si c’est juste un troll mais ça y ressemble.

Je n’ai rien contre le format INI, mais les conclusions sont bourrées de biais et surtout de manque de détails.

Prenons par exemple Ansible. L’utilisation du YAML n’a pas été fait par défaut mais parce qu’il n’est pas un simple fichier "texte", il peut être perçu comme un DSL et il permet le multiline.

L’exemple donné ne représente pas la réalité. Voilà un exemple, qui utilise du "multiligne":

- name: Lance quelques ligne de bash
  shell: |
    cp truc machin
    tar cf machin.tar /ici
    for i in une_lise; then
      # faire des choses ici...
    fi

En INI c’est juste impossible à faire…

Et en ce qui concerne la répétition de clefs dans un fichier INI, cela permet à un humain de les déplacer dans le bloc, et donc de rendre le fichier aussi bordélique qu’une chambre d’ado.

Le XML, OK c’est lourd à "taper" et pas marrant à lire pour un humain, mais je rappelle qu’une configuration n’est pas forcément éditée à la main - le XML permet une validation de format (e.g via XMLint). Donc de ne pas charger ou sauver un fichier tout pété avec des erreurs de noms de clef par exemple.

Et de la même manière, un fichier XML peut contenir du multiligne.

Le INI ça suffit pour de la petite configuration ou quand le besoin le permet (e.g. PHP utilise des fichier INI pour la config, parce que il n’y a aucun besoin de structurer les options), mais quand on a une "structure" de configuration, avec possiblement des blocs de texte, des sous arbres, etc… le YAML ou encore le TOML sont bien plus adaptés si on veut permettre une lecture/écriture humaine, et une vraie structure lisible, sinon du JSON (par ce que c’est simple à générer), et si on a un vrai besoin de vérification d’entité et de format, le XML est très adapté.

En gros, l’exemple Ansible est moisi… désolé mais quiconque a déjà travaillé sur Ansilble te dira qu’en INI ce serait juste l’enfer. Et non, ton exemple n’est pas plus lisible en INI, c’est tout l’inverse.

Bref, le INI c’est sympa mais super limité. Ça va pour de la petite config, mais les exemples donnés dans l’article sont des vues biaisées.

EDIT: j’oubliais, YAML permet de taguer des entités, et par conséquent un langage bien foutu comme le Python peut lire le fichier et utiliser les tags pour savoir quel type utiliser. Genre:

- !!python/object:__main__.User
  name: Foo
  age: 32

Ici, Python va lire le fichier et tenter de me sortir non pas un dictionnaire, mais un objet de type User. Et il sait justement enregistrer en YAML avec ces tags. Bref, conclusion de l’article limitée selon moi.

En fait, pas tout à fait. Déjà, la plupart des bibliothèques INI gèrent les caractères d’échappement. Certains gèrent même l’échappement de la ligne, c’est la méthode qu’a choisi Makefile pour pouvoir exécuter des instructions dans un même SHELL.

Puis je ne suis pas certain qu’avoir un script dans son fichier YAML soit vraiment une bonne pratique…

Par-contre, le tag des entités, c’est super utile pour la sérialisation ! J’ai déjà dit ce que je pensais de la sérialisation textuelle ?

Bref, je ne dis pas qu’Ansible aurait dû utiliser INI. Je dis juste que le choix de YAML est discutable. TOML aurait été un choix correct je pense.

Impossible dis-tu ? Dans ce cas que penses-tu de ceci (mise à part que ce n’est pas à ton goût) ?

[Lance quelques ligne de bash]
SHELL= cp truc machin
SHELL= tar cf machin.tar /ici
SHELL= for i in une_lise; then
SHELL=     # faire des choses ici...
SHELL= done

Ou de ça

[Lance quelques ligne de bash]
SHELL=EOT
cp truc machin
tar cf machin.tar /ici
for i in une_lise; then
    # faire des choses ici...
done
EOT

Ou encore de ceci ?

[Lance quelques ligne de bash]
SHELL=cp truc machin \
tar cf machin.tar /ici \
for i in une_lise; then \
    # faire des choses ici... \
done

Ceci étant dit, mon billet ne part pas du principe que des bibliothèques existantes doivent être utilisées, ni que le format choisi préexiste, ni qu’il ne doit pas être étendu. Le message principal du billet n’est pas « vive le format INI », mais « réfléchissez avant de choisir un format et, si cela amène plus de simplicité, construisez le vôtre ».

Je n’ai pas saisi ce que tu veux dire ici.

Je n’ai jamais prétendu le contraire.

C’est ton point de vue.