Formateur et validateur TOML

TOML (Tom's Obvious Minimal Language) est un format de fichier de configuration conçu pour être facile à lire et à écrire. Contrairement à YAML, TOML évite les espaces blancs significatifs et les imbrications complexes qui causent des bugs subtils. Contrairement à JSON, TOML prend en charge les commentaires, dispose de types de date/heure natifs et est plus convivial pour les fichiers de configuration. TOML échange une partie de la flexibilité de YAML contre la prévisibilité — il n'y a généralement qu'une seule façon d'exprimer quelque chose en TOML.

Une table TOML est une collection de paires clé-valeur sous un en-tête comme [package] ou [dependencies]. Les tables peuvent être imbriquées à l'aide d'en-têtes en pointillés comme [server.database]. Les tables inline sont une syntaxe compacte sur une seule ligne utilisant des accolades : key = { name = 'value', version = '1.0' }. Les tables régulières sont meilleures pour la lisibilité avec de nombreuses clés, tandis que les tables inline conviennent bien aux petits groupes de valeurs étroitement liées.

Rust a choisi TOML pour Cargo car il offre un équilibre entre lisibilité humaine et analyse par machine. Le typage explicite de TOML (chaînes, entiers, booléens, dates) réduit l'ambiguïté qui affecte YAML (où 'no' peut être interprété comme un booléen). Son support des commentaires est essentiel pour documenter les choix de dépendances. La simplicité du format signifie également moins de cas limites d'analyse et un comportement plus prévisible entre différents outils et éditeurs.

Les tableaux de tables utilisent des doubles crochets [[table_name]] pour définir plusieurs instances du même type de table. Par exemple, [[bin]] dans Cargo.toml définit plusieurs cibles binaires. Chaque bloc [[bin]] ajoute un nouvel élément à un tableau. C'est la façon dont TOML représente des tableaux d'objets sans le bruit visuel des tableaux JSON ou des listes basées sur des tirets de YAML.

pyproject.toml est le fichier de configuration de projet standardisé de Python (défini dans PEP 518 et PEP 621). Il remplace l'ancienne approche setup.py et setup.cfg. La table [build-system] spécifie les exigences de construction, [project] contient des métadonnées comme le nom, la version et les dépendances, et les tables [tool.*] contiennent la configuration pour des outils spécifiques comme pytest, black ou mypy. Cela consolide plusieurs fichiers de configuration en un seul emplacement standard.