Convertir YAML en INI

Toute la conversion tient dans cette phrase. Un fichier INI est une liste de sections, chacune contenant des lignes plates clé-valeur, et il n’existe aucun moyen d’imbriquer une section dans une section. Le format n’a pas de spécification — il date de 1985, précède l’idée qu’un format de configuration en aurait besoin une, et chaque analyseur a des opinions légèrement différentes sur les guillemets, les commentaires et les booléens. C’est pourquoi le registre le marque comme hérité plutôt que comme actuel.

YAML imbrique sans limite et porte des types, des ancres et des références. La conversion doit donc projeter un arbre arbitrairement profond sur deux niveaux, et la question intéressante n’est pas de savoir si cela fonctionne mais ce qu’elle fait du troisième niveau et de tout ce qui se trouve en dessous. La réponse courte est qu’elle conserve les données et abandonne la structure, ce qui est le bon compromis dans le sens où un fichier de configuration voyage en général.

Chaque clé de premier niveau dont la valeur est un mapping devient une section : un fichier contenant les objets server, logging et database produit [server], [logging] et [database], avec les clés à l’intérieur écrites en dessous. Pour des réglages écrits à l’origine par une personne, c’est très souvent une correspondance exacte, et la sortie est le fichier que vous auriez tapé à la main.

Les clés de premier niveau tenant une valeur scalaire — un drapeau de débogage, un numéro de version, un nom d’environnement — sont écrites au-dessus du premier en-tête de section plutôt qu’après. Ce n’est pas un choix de style : une section INI s’approprie chaque ligne qui la suit jusqu’à l’en-tête suivant, de sorte qu’une clé nue écrite plus bas deviendrait membre de la section précédente et changerait de sens.

Un troisième niveau d’imbrication est écrit en clé pointée. Si server contient un objet tls contenant un chemin de certificat, la sortie est une section [server] contenant une ligne tls.cert. Rien n’est écarté, et le chemin qui ramène à la forme d’origine est inscrit dans le nom de la clé, ce qui est exactement la convention que configparser de Python et la plupart des lecteurs INI modernes reconnaissent.

Cette reconstruction dépend du lecteur. Certains analyseurs INI comprennent la convention et reconstituent l’imbrication ; la plupart ne le font pas, et traitent tls.cert comme une clé qui se trouve contenir un point. L’un ou l’autre convient en général pour lire un réglage. Ce qui ne l’est pas, c’est l’aller-retour en général : une clé YAML qui contient réellement un point devient indiscernable d’un niveau d’imbrication, et aucun lecteur ne peut dire laquelle des deux elle était.

INI ne stocke que des chaînes. Un true YAML s’écrit true, un 8080 YAML s’écrit 8080, un null YAML s’écrit comme une clé sans valeur, et ce que ces valeurs signifient ensuite est décidé par ce qui lira le fichier. Le configparser de Python rend la chose explicite avec getboolean et getint, et il accepte yes, on et 1 pour true également.

Cela mérite de savoir dans quel sens va la devinette de votre analyseur avant de se fier à une valeur. Une chaîne de version 1.0 est du texte dans YAML et sera très probablement relue comme un nombre ; un identifiant avec des zéros initiaux les perd dès que quelque chose le traite comme un entier. Quand cela compte, la correction se fait dans l’application qui lit le fichier plutôt que dans le fichier lui-même.

La clé survit et la valeur ne survit pas : un null sort en clé, signe égal et rien. C’est ce qui se rapproche le plus d’une valeur non définie en INI, puisque le format n’a ni null ni moyen d’en exprimer un. La distinction « clé absente » et « clé présente et vide » est donc perdue à la lecture : les deux finissent falsy.

Ce que votre analyseur en fait varie, et cela mérite dix secondes pour s’en assurer. Le configparser de Python renvoie une chaîne vide. Certains lecteurs renvoient eux aussi la chaîne vide mais la traitent comme false dans un contexte booléen, et quelques-uns ignorent la clé. Si la différence entre « réglé à rien » et « non réglé » pilote le comportement de l’application, supprimez ces lignes à la main plutôt que de livrer l’ambiguïté.

INI n’a pas de liste. Un tableau de trois hôtes autorisés devient trois lignes indexées 0, 1 et 2 sous la section parente, ce qui préserve chaque valeur et ne correspond à presque aucune convention d’analyseur. Les formats qui acceptent des listes attendent en général une seule ligne avec les valeurs séparées par des virgules, et quelques-uns attendent la même clé répétée.

C’est la partie de la conversion qui mérite d’être modifiée dans YAML avant l’opération plutôt que dans INI après. Joignez la liste en une seule chaîne avec le séparateur qu’attend l’application, convertissez, et la sortie est une ligne que l’analyseur lit nativement. Faire la chose dans l’autre sens oblige à éditer à la main chaque groupe numéroté, et la première fois que la liste change de longueur, le code qui en dépendait casse sans avertissement.

Une liste YAML au plus haut niveau produit des sections nommées d’après les positions de la liste : [0], [1], [2], chacune contenant les clés d’un enregistrement. Le fichier est syntaxiquement un INI valide et il n’existe aucun programme sensé qui le lise.

Cette sortie est un signal plutôt qu’un échec. INI est un format de configuration — un ensemble de réglages nommés pour une seule application — et une liste d’enregistrements est une donnée. Si ce que vous avez est une liste, CSV ou tableur est la cible si une personne doit la lire, et JSON ou base de données si c’est un programme. La conversion ne refuse pas, parce qu’un fichier à un enregistrement est un objet légitime à vouloir, mais une suite de sections numérotées signifie que la réponse à la question initiale était non.

YAML a des ancres et des alias, qui permettent de définir un bloc une fois (&id) et de le référencer à trois endroits (*id). Les fichiers compose et les bundles Kubernetes s’appuient dessus. La conversion ne reproduit pas cette économie : chaque référence est résolue en une copie complète du bloc, ce qui est correct mais multiplie les octets.

Pour un manifeste de déploiement typique, c’est rarement un problème, parce que les sections partagées sont petites. Pour un fichier où la même longue structure est référencée vingt fois, la sortie sera vingt fois plus longue que la source, et la compression en aval ne récupérera qu’une partie. Si la taille compte, déplier les ancres à la main en YAML avant la conversion est l’édition qui vaut la peine.

YAML a trois styles de chaînes : nues, entre apostrophes et entre guillemets, plus les scalaires bloc avec un pipe ou un chevron. INI n’a rien de tout cela : une valeur est une suite de caractères jusqu’à la fin de la ligne. La conversion écrit donc les chaînes multi-lignes sur une seule ligne, avec barre oblique et n pour les sauts internes, ce que la majorité des lecteurs INI déballent correctement.

Cette neutralisation est sans perte pour un aller-retour INI-vers-YAML réalisé avec le même convertisseur, mais un autre programme qui lirait le fichier INI peut très bien laisser les deux caractères au lieu d’un saut de ligne. Quand la fidélité compte — un script embarqué, un certificat en PEM, une instruction SQL sur huit lignes — la place correcte de cette valeur est dans son propre fichier, INI ne portant qu’un chemin. La conversion entoure aussi de guillemets doubles les valeurs qui commencent ou finissent par un blanc, parce que la majorité des lecteurs INI supprimeraient ces blancs sinon, et toute valeur contenant un signe égal, un point-virgule ou un dièse, parce que ces caractères ont une signification syntaxique pour INI et casseraient la ligne sans protection.

YAML accepte un commentaire n’importe où sur une ligne, après un dièse, et un fichier produit par une personne en est généralement plein. La sortie n’en porte aucun, parce que INI n’a pas de syntaxe pour les accueillir. INI en accepte, mais avec un point-virgule ou un dièse en début de ligne, ce que le convertisseur ne génère pas.

Puisque l’intérêt de déplacer des réglages dans INI est en général qu’une personne va les éditer, les lignes de commentaire valent la peine d’être ajoutées immédiatement : quelles valeurs sont spécifiques à l’environnement, laquelle doit correspondre à une valeur ailleurs, et quelle section l’application ignore complètement. C’est précisément l’information qu’YAML généré n’a pas pu porter, et c’est la première édition qui rend le fichier utile.