Entwicklertools · Syntaxkonverter
Warum TOML existiert: die Designziele hinter Cargo.toml und pyproject.toml
· Hintergrund
toml Datenformate Entwickler-Workflow
TOML wurde in 2013 als Reaktion auf die Sparmaßnahmen von JSON und die Unklarheit von YAML erstellt. In diesem Beitrag werden die erklärten Designziele, die daraus resultierenden Entscheidungen und die Gründe erläutert, warum Rust und Python für die Projektkonfiguration darauf standardisiert haben.
Drei Konfigurationsformate in einem Repository – JSON für den Editor, YAML für CI, TOML für den Build und die Frage, warum das dritte existiert
Ein Repository kann JSON, YAML und TOML für verschiedene Konfigurationsoberflächen verwenden. ToolAcre kann nicht die Wahl jedes Projekts erklären, aber die Konvertierung macht die strukturellen Unterschiede konkret: TOML beginnt als Stammtabelle, verwendet Kopfzeilen und gepunktete Pfade zur Verschachtelung und enthält zeitliche Werte, die in JSON nicht verfügbar sind.
Laden Sie das Beispiel, anstatt über das Aussehen zu argumentieren. Verschachtelte Tabellen werden zu Objekten, Tabellen mit doppelten Klammern werden zu Arrays und Kommentare verschwinden, wenn Werte JSON eingeben. Diese beobachteten Grenzen sind umsetzbarer als die allgemeine Behauptung, dass eine Syntax von Natur aus besser ist.
Die Designziele – minimale, offensichtliche Semantik, einfache Lesbarkeit und ein Format, das eindeutig einer Hash-Tabelle zugeordnet werden kann
Der mitgelieferte Parser legt die offensichtliche Tabellensemantik offen: Header sind Pfade, Zuweisungen gehören zur aktiven Tabelle und skalare Token haben definierte TOML-Typen. Zeichenfolgen werden nicht nur deshalb typisiert, weil ihr Inhalt wie Datumsangaben aussieht; Die tatsächliche zeitliche Syntax erzeugt Datumsobjekte, die ToolAcre absichtlich normalisiert.
Das Repository enthält keine Angaben zu den Urhebern, Daten oder der erklärten Philosophie des Formats, daher vermeidet dieser Artikel die Darstellung erinnerter Geschichte als Tatsache. Es meldet das in smol-toml und der eigenen Normalisierungsschicht des Konverters getestete Verhalten.
Beobachtbare Designeigenschaften im mitgelieferten Parser, ohne unbegründete Herkunftsansprüche
TOML hat keine Null und sein Dokumentstamm darf kein Array oder Skalar sein. In dieser Zuordnung werden keine Anker oder Aliase im YAML-Stil bereitgestellt. Kommentare sind im erstellten TOML vorhanden, werden jedoch nicht vom Wertparser beibehalten und können daher die Konvertierung durch JSON oder YAML nicht überleben.
Nicht zitierte bloße Werte folgen der Grammatik von TOML und nicht der Schemaauswahl von YAML. Der Parser akzeptiert entweder einen typisierten Wert oder meldet ungültige TOML mit Positionsinformationen. ToolAcre fügt keinen impliziten Zeichenfolgenmodus für fehlerhafte Zuweisungen hinzu.
Was das unterstützte Wertemodell ausschließt oder anders behandelt
Das Modell umfasst Zeichenfolgen, ganze Zahlen mit Vorzeichen, Gleitkommazahlen, boolesche Werte, vier zeitliche Arten, Arrays und Tabellen. Tabellenarrays drücken wiederholte Objektdatensätze aus. Große Ganzzahlen mit Vorzeichen über 2^53 hinaus werden bei der Konvertierung zu Dezimalzeichenfolgen, sodass JavaScript sie nicht stillschweigend rundet.
Zeitwerte werden zum quellenorientierten Text für Offset-Datum/Uhrzeit, lokales Datum/Uhrzeit, lokales Datum oder lokale Uhrzeit. Die Warnung behält die Art in Prosa bei, aber JSON erhält nur eine Zeichenfolge. Bei der Rückkonvertierung wird es daher in Anführungszeichen gesetzt und der native Typ TOML geht verloren.
Übernahme – Ladung aus den Anfängen von Rust, PEP 518 wählt pyproject.toml und die 1.0.0-Spezifikation in 2021
Die Übernahme von Fracht und Pyprojects sind historische und Ökosystemansprüche, die Quellen erfordern, die nicht im Konverter-Repository vorhanden sind. Sie werden hier bewusst weggelassen. Ein Pfad oder Dateiname ist kein Beweis für eine Chronologie, Spezifikationsveröffentlichung oder Standardentscheidung.
Die operative Frage ist, ob das Zieltool TOML liest und welche Tabellen es erwartet. Sehen Sie sich die aktuelle Dokumentation des Tools an. Syntaxkonverter kennen Syntax und Wertezuordnung, nicht Paketmanager-Konfigurationsverträge.
Der Verlauf der Ökosystemeinführung wird ohne Repository-Quellen weggelassen
Eine tiefe Verschachtelung kann schwieriger zu scannen sein, da der Tabellenkontext zeilenübergreifend bestehen bleibt, während große Tabellenarrays eine logische Liste über wiederholte Header verteilen. JSON macht die gesamte Hierarchie explizit, fügt jedoch geschweifte Klammern und Anführungszeichen hinzu. Keine der Darstellungen verringert die Komplexität der zugrunde liegenden Konfiguration.
Der Parser begrenzt die Verschachtelung auf 100 und die Quelllänge auf zwei Millionen Zeichen. Hierbei handelt es sich um Ablehnungsgrenzen, nicht um Aussagen über die ideale Konfigurationsgröße oder universelle TOML-Grenzwerte.
Was dies nicht abdeckt – TOML Parser-Auswahl in jeder Sprache und die schreibgeschützte Natur einiger Standardbibliotheksimplementierungen
Die Wahl des Parsers in jeder Sprache liegt außerhalb des Anwendungsbereichs, ebenso wie die Schreibfunktionen der Standardbibliothek. ToolAcre verwendet smol-toml dynamisch und umschließt seine Fehler. Eine andere Implementierung kann gültige Ausgaben anders formatieren oder eine andere API verfügbar machen, während dieselben Daten dargestellt werden.
Verwenden Sie werkzeugübergreifende Vorrichtungen für Zeitwerte, große Ganzzahlen, Arrays und Punktschlüssel, wenn es auf Interoperabilität ankommt. Eine hier akzeptierte Datei wird nicht automatisch von jedem TOML-Consumer akzeptiert.
Fazit: TOML ist der Meinung, dass es sich um ein Konfigurationsformat handelt – und wie Sie im Syntaxkonverter-Bedienfeld jede JSON- oder YAML-Datei in dieser Form sehen können
TOML hat eine Meinung auf beobachtbare Weise: Tabellenstamm, explizite typisierte Werte, native temporale Arten und keine Null. Die Konvertierung deckt diese Entscheidungen und ihre Inkompatibilität mit JSON-förmigen Zielen auf, ohne dass es eines Ursprungsmythos bedarf.
Verwenden Sie das Panel, um einen Baum zu untersuchen und Warnungen zu identifizieren. Kehren Sie dann zum Schema des Ziels zurück und erstellen Sie das Tabellenlayout, das von Menschen beibehalten wird. Der Konverter liefert Hinweise zu Werten, kein Urteil über die Formatpräferenz.
Die gleiche Disziplin gilt, wenn TOML nur eine Zwischenansicht ist. Behalten Sie die Quelle bei, vergleichen Sie normalisierte Werte und notieren Sie jede zeitliche oder ganzzahlige Konvertierung, bevor Sie die Lesbarkeit beurteilen. Ein kompaktes Tabellenlayout kann einen geänderten Typ immer noch verbergen, während ein ausführliches Tabellenarray semantisch exakt sein kann. Die Wahl des Formats sollte sich am Konfigurationsvertrag und am Wartungsablauf orientieren und nicht an der visuellen Sauberkeit eines generierten Beispiels.