Convertir INI en YAML

Chaque en-tête de section devient une clé de premier niveau et ses réglages sont indentés de deux espaces en dessous. Les clés écrites au-dessus du premier en-tête de section restent au premier niveau, à côté de ces blocs. La sortie utilise des espaces partout — YAML interdit les tabulations pour l’indentation, et un convertisseur qui en émettrait produirait un fichier qu’aucun analyseur n’accepte.

Le résultat est un document YAML valide, pas un fragment. La distinction compte quand la destination est un fichier de valeurs ou un jeu de variables, parce qu’on voudra en général que l’ensemble soit imbriqué d’un niveau supplémentaire sous une clé propre, et il est plus facile d’indenter un document dont on sait qu’il est correct que de raisonner sur un fragment.

Les fichiers INI disent On et Off bien plus souvent qu’ils ne disent true et false. php.ini le fait, les fichiers de configuration Windows le font, et quantité de daemons le font. Le lecteur ici ne traite pas ces mots comme des booléens, ils restent des chaînes, et l’écriture les émet sans guillemets : engine: On.

La question de savoir si cette ligne signifie une chaîne ou un booléen dépend de la version de YAML qu’implémente votre parseur. YAML 1.2, la version que le registre retient pour le format et celle qu’implémente le parseur de cette page, en fait la chaîne « On ». YAML 1.1 en fait le booléen true, et PyYAML implémente 1.1 — ce qui signifie qu’Ansible, et une longue traîne d’outillage Python, liront cette ligne comme un booléen. Il en va de même pour yes, no, y et n.

La correction se fait en ajoutant des guillemets, et elle doit être faite à la main parce que le convertisseur ne peut pas distinguer quelles valeurs On étaient voulues comme commutateurs. Écrivez engine: "On" si vous voulez la chaîne dans tous les parseurs, ou engine: true si vous voulez le booléen dans tous les parseurs. Les deux sont non ambigus sous 1.1 et 1.2, ce qui est la seule propriété qui vaille la peine d’être visée.

Mieux vaut faire ce passage de manière délibérée plutôt que de corriger celles qui cassent. Un booléen lu comme une chaîne est en général truthy et reste donc silencieusement activé, et une chaîne lue comme un booléen fait en général échouer une vérification de schéma bruyamment — la direction dangereuse est donc la plus discrète, celle où un réglage désactivé revient activé et où rien ne se manifeste jusqu’à ce que quelque chose se manifeste.

Le typage se produit à la lecture de l’INI, pas à l’écriture du YAML, si bien qu’au moment où l’écriture YAML tourne la décision est déjà prise. Les valeurs qui s’analysent comme des nombres finis deviennent des nombres, true et false deviennent des booléens ; tout le reste reste une chaîne.

Trois cas dans un fichier de configuration ressortent modifiés. Une version épinglée à 1.0 devient 1. Un mode de fichier écrit 0755 devient 755, ce qui n’est pas le même mode. Un masque hexadécimal écrit 0x1F devient 31. Les valeurs portant une unité sont préservées, donc 128M reste 128M et 30s reste 30s, et il en va de même pour des adresses comme 127.0.0.1 et des horaires comme 08:00, dont aucun ne s’analyse comme un seul nombre.

Un en-tête écrit [tool.pytest] ou [mail.smtp] devient une clé nommée exactement ainsi, et non deux niveaux d’imbrication. Le lecteur prend tout ce qui se trouve entre les crochets comme un seul nom, ce qui est la seule lecture défendable — dans php.ini, les clés et les sections sont pleines de points qui font partie du nom.

YAML accepte une telle clé sans guillemets, la sortie est donc valide et se lit bien. Ce n’est pas non plus ce qu’attend une chart Helm ou un rôle Ansible, où mail.smtp.host ferait en général trois niveaux. Le découpage est une édition manuelle et délibérée, parce qu’on y décide quelque chose que le fichier source n’a jamais dit.

Les configurations assemblées en ajoutant à un fichier de base une surcouche d’environnement finissent par présenter deux fois le même en-tête de section. Le lecteur crée une section vide neuve à chaque en-tête rencontré, si bien que seule la dernière occurrence survit et que la précédente disparaît sans message.

Cela mérite d’être vérifié avant la migration plutôt qu’après, parce que la sortie est un YAML bien formé auquel manquent simplement des réglages, et qu’une clé absente dans un déploiement se manifeste en général par une valeur par défaut appliquée silencieusement plutôt que par une erreur. Cherchez d’abord les en-têtes en doublon dans l’INI ; la même règle du dernier qui gagne s’applique à une clé répétée à l’intérieur d’une section.

YAML accepte des commentaires et INI accepte des commentaires, et aucun des vôtres ne survit à cette conversion. Les lignes de commentaire sont ignorées à la lecture et rien ne les réécrit, si bien qu’un fichier qui était à moitié explication arrive en tant que réglages purs.

Sur une configuration éditée en place depuis des années, ces commentaires sont la mémoire institutionnelle : la note indiquant qu’un timeout a été augmenté pour un rapport, le bloc commenté pendant un incident et jamais retiré, les initiales et la date à côté d’une valeur que personne ne veut toucher. Copiez le fichier INI d’origine dans le dépôt au même commit que le YAML. Cela ne coûte rien, et c’est le seul endroit où subsiste ce raisonnement.

Le lecteur et l’écriture sont tous deux du JavaScript dans cette page, si bien que le fichier n’est jamais envoyé nulle part. C’est une propriété générale des conversions de données ici, et c’est sur cette paire qu’elle prend tout son sens : le fichier INI qu’on migre au loin d’un vieux serveur est très souvent celui qui contient le mot de passe de la base, les identifiants SMTP et les clés d’API.

Le plafond gratuit est de 100 Mo, ce qu’aucun fichier de configuration n’atteint. En pratique, la conversion est instantanée, et la seule chose qui mérite d’être faite lentement ensuite est de lire la sortie — parce qu’à partir du moment où ces secrets sont dans un YAML d’un dépôt, ils le sont dans l’historique du dépôt pour de bon, et c’est une décision à prendre avant le commit, pas après.

Si l’application lit encore de l’INI et le fera toujours, convertir est du churn. YAML apporte l’imbrication, les listes, les commentaires en revue et un linter, et rien de tout cela n’aide un programme dont l’analyseur attend des sections et des signes égal. La migration vaut le coup quand la configuration entre dans un système qui lit du YAML nativement, et non quand le fichier a seulement l’air ancien.

L’autre bonne raison de s’arrêter est la taille. Un fichier de trois sections et vingt clés est plus rapide à retaper dans la structure cible qu’à convertir puis à remodeler, et retaper oblige à lire chaque valeur une fois. Utilisez le convertisseur quand le fichier est assez gros pour que le lire à la main soit l’option la plus sujette à erreur.