Ist es .yaml oder .yml?

Question

Laut yaml.org ist die offizielle Dateierweiterung .yaml.

Zitat:

Gibt es eine offizielle Erweiterung für YAML-Dateien?

Bitte verwenden Sie ".yaml", wenn möglich.

Es scheint jedoch Uneinigkeit im Internet darüber zu geben, welche Erweiterung verwendet werden soll. Wenn Sie sich im Web Beispiele ansehen, verwenden viele von ihnen die nicht genehmigte Erweiterung .yml.

Eine Suche bei Google ergibt fast 3-mal so viele Ergebnisse für die kürzere Version.

---

49.100

---

15.400

---

Also, welche Erweiterung soll ich verwenden? Die von dem Ersteller vorgeschlagene korrekte 4-Buchstaben-Erweiterung oder die 3-Buchstaben-Erweiterung, die im wilden Westen des Internets zu finden ist?

Answer 1

Die Natur und sogar das Vorhandensein von Dateierweiterungen ist plattformabhängig (einige obskure Plattformen haben sie nicht einmal, erinnern Sie sich) - in anderen Systemen sind sie nur konventionell (UNIX und ähnliches), während sie in anderen definitierte Semantik haben und in einigen Fällen spezifische Grenzen für Länge oder Zeicheninhalt haben (Windows usw.).

Da die Betreiber darum gebeten haben, ".yaml" zu verwenden, ist das so nah wie möglich an einer "offiziellen" Regelung, aber die Gewohnheit von 8.3 ist schwer abzulegen (und leider 2013 noch gelegentlich relevant).

Answer 2

Bearbeiten:

Also, was soll ich verwenden? Die richtige 4-Buchstaben-Erweiterung, die vom Ersteller vorgeschlagen wurde, oder die 3-Buchstaben-Erweiterung, die im Wilden Westen des Internets zu finden ist?

Diese Frage könnte sein:

1. Eine Bitte um Rat; oder

2. Ein natürlicher Ausdruck jenes speziellen Gefühls, das man erlebt, während man beobachtet, dass eine offizielle Empfehlung missachtet wird - hervorstechend oder sogar vorherrschend.

Die Menschen unterscheiden sich in ihrer Vorliebe für:

1. Offizielle Ratschläge; oder

2. Die vorherrschende Praxis.

Natürlich bin ich unwahrscheinlich, Sie in Bezug darauf zu beeinflussen, welchen dieser beiden Wege Sie bevorzugen!

Im Folgenden (und im Geiste der Wissenschaft) stelle ich lediglich eine Hypothese auf, warum die Mehrheit der Menschen die 3-Buchstaben-Erweiterung verwendet hat. Und ich konzentriere mich auf effiziente Ursachen.

Dabei meine ich keine moralische Ermahnung. Wie Sie sich erinnern können, bedeutet die Tatsache, dass etwas ist, nicht, dass es sein sollte.

Unabhängig von Ihrer persönlichen Neigung, ob Sie einem Pfad oder dem anderen folgen möchten, habe ich nichts einzuwenden.

(Ende der Bearbeitung.)

Die Behauptung, dass diese Vorliebe (in der tatsächlichen Verwendung) durch eine 8.3-Zeichen-DOS-ähnliche Beschränkung verursacht wurde, ist meiner Meinung nach ein Ablenkungsmanöver (irreführend und irreführend).

Im August 2016 betrugen die Google-Suchergebnisse für YML und YAML ungefähr 6.000.000 bzw. 4.100.000 (auf zwei Dezimalstellen genau). Darüber hinaus war die "YAML"-Anzahl unverhältnismäßig hoch, weil sie die Erwähnung der Sprache bei Namen einschloss, jenseits ihrer Verwendung als Erweiterung.

Im Juli 2018 beliefen sich die Google-Suchergebnisse für YML und YAML auf etwa 8.100.000 bzw. 4.100.000 (wieder auf zwei Dezimalstellen genau). In den letzten zwei Jahren hat YML an Popularität quasi verdoppelt, während YAML gleich geblieben ist.

Ein weiteres kulturelles Maß ist die Anzahl der Websites, die versuchen, Dateierweiterungen zu erklären. Beispielsweise führte die Seite "FilExt" (Stand Juli 2018) für YAML zu dem Ergebnis: "Ups! Die FILEXT.com-Datenbank enthält keine Informationen zur Dateierweiterung .YAML."

Hingegen gibt es einen Eintrag für YML, der besagt: "YAML... verwendet eine Textdatei und organisiert sie in ein Format, das für Menschen lesbar ist. 'database.yml' ist ein typisches Beispiel, wenn YAML von Ruby on Rails verwendet wird, um eine Verbindung zu einer Datenbank herzustellen."

Im November 2014 erklärte der Wikipedia-Artikel zur Erweiterung YML noch, dass ".yml" "die" Dateierweiterung für das YAML-Dateiformat sei (Hervorhebung hinzugefügt). Der YAML-Artikel listet beide Erweiterungen auf, ohne eine Präferenz auszudrücken.

Die Erweiterung ".yml" ist ausreichend klar, kürzer (und damit einfacher zu tippen und zu erkennen) und viel verbreiteter.

Natürlich könnten beide Erweiterungen als Abkürzungen einer langen möglichen Erweiterung, ".yamlaintmarkuplanguage", angesehen werden. Aber Programmierer (und Benutzer) möchten das alles nicht eingeben!

Stattdessen möchten wir Programmierer (und Benutzer) so wenig wie möglich eingeben und dennoch eindeutig und klar sein. Und wir möchten schnell erkennen, um welche Art von Datei es sich handelt, ohne ein längeres Wort lesen zu müssen. Welche Anzahl von Zeichen erfüllt beide Ziele? Ist die Antwort nicht drei (3)? Mit anderen Worten, YML?

Wikipedias Kategorie:Dateierweiterungen führt Einträge für .a, .o und .Z auf. Seltsamerweise wurden .c und .h (von der C-Sprache verwendet) nicht erwähnt. Diese Beispiele für einzeilige Erweiterungen helfen uns zu erkennen, dass Erweiterungen so lang sein sollten, wie nötig, aber nicht länger (um Albert Einstein zu zitieren).

Bemerkenswert ist darüber hinaus, dass nur wenige Erweiterungen allgemein mit "Y" beginnen. Dagegen wird allgemein der Buchstabe X für eine Vielzahl von Bedeutungen verwendet, darunter "Kreuz", "erweiterbar", "extrem", "variabel" usw. (z. B. in XML). Mit "Y" zu beginnen, übermittelt bereits viel Informationen (in Bezug auf die Informationstheorie), während das Beginnen mit "X" dies nicht tut.

Linguistisch gesehen hat das Akronym "XML" (auf gewisse Weise) nur zwei informative Buchstaben ("M" und "L"). "YML" hingegen hat drei informative Buchstaben ("M", "L" und "Y"). Tatsächlich ist die Liste der bestehenden Akronyme, die mit "Y" beginnen, äußerst kurz. Dadurch wird deutlich, warum eine vier Buchstaben lange YAML-Dateierweiterung als stark über spezifiziert empfunden wird.

Möglicherweise ist dies der Grund, warum wir in der Praxis feststellen, dass der "linguistische" Druck (bei der natürlichen Verwendung) schwach ist, die Abkürzung auf vier (4) Zeichen zu verlängern, während der "linguistische" Druck, diese Abkürzung auf drei (3) Zeichen zu verkürzen, stark ist.

Allein als Ergebnis wahrscheinlich dieser Faktoren (und nicht als offizielle Empfehlung) möchte ich darauf hinweisen, dass die aktuellsten Neuigkeiten der YAML.org-Website (von November 2011) alles über ein Projekt in JavaScript, JS-YAML, sind, das selbst intern die Erweiterung ".yml" bevorzugt.

Die oben genannten Faktoren mögen die Hauptfaktoren gewesen sein; dennoch haben alle (bekannten oder unbekannten) Faktoren dazu geführt, dass die abgekürzte, dreistellige Erweiterung die vorherrschende für YAML ist - trotz der Vorliebe der Erfinder.

".YML" scheint der de facto Standard zu sein. Dennoch waren die gleichen Erfinder scharfsinnig und korrekt hinsichtlich des Bedarfs der Welt an einer menschenlesbaren Datensprache. Und wir sollten ihnen dafür danken, dass sie dies bereitgestellt haben.

Answer 3

.yaml ist anscheinend die offizielle Erweiterung, da einige Anwendungen fehlschlagen, wenn .yml verwendet wird. Andererseits bin ich nicht mit Anwendungen vertraut, die YAML-Code verwenden, aber bei einer .yaml-Erweiterung versagen.

Ich bin gerade darüber gestolpert, da ich es gewohnt war, .yml in Ansible und Docker Compose zu schreiben. Aus Gewohnheit habe ich beim Schreiben von Netplan-Dateien .yml verwendet, was still scheiterte. Schließlich habe ich meinen Fehler herausgefunden. Der Autor einer beliebten Ansible Galaxy-Rolle für Netplan macht dieselbe Annahme in seinem Code:

- name: Bestehende Konfigurationen erfassen
  find:
    paths: /etc/netplan
    patterns: "*.yml,*.yaml"
  register: _netplan_configs

Doch alle Dateien mit der .yml-Erweiterung werden von Netplan genauso ignoriert wie Dateien mit einer .bak-Erweiterung. Da Netplan sehr ruhig ist und überhaupt kein Feedback zum Erfolg gibt, selbst mit netplan apply --debug, wird eine Konfiguration wie 01-netcfg.yml still scheitern, ohne sinnvolles Feedback.

Answer 4

Nachdem ich eine Menge Kommentare von Leuten online darüber gelesen habe, war meine erste Reaktion, dass dies im Grunde genommen eine dieser wirklich unwichtigen Debatten ist. Allerdings war mein erstes Interesse, das richtige Format herauszufinden, damit ich konsistent mit meiner Dateibenennungspraxis sein könnte.

Um es kurz zu machen, der Schöpfer von YAML sagt .yaml, aber persönlich benutze ich weiterhin .yml. Das macht für mich einfach mehr Sinn. Also machte ich mich auf die Reise, um Bestätigung zu finden und bald darauf merkte ich, dass Docker überall .yml verwendet. Ich habe die ganze Zeit Dateien mit docker-compose.yml geschrieben, während du in den Docs von Kubernetes immer kubectl apply -f *.yaml siehst...

Also, zusammenfassend, beide Formate sind offensichtlich akzeptiert und wenn du auf der anderen Seite bist (dh: Systeme schreibst, die eine YAML-Datei als Eingabe erhalten), solltest du beide zulassen. Das scheint wie eine weitere Snake-Case gegen Camel-Case Sache zu sein...

Answer 5

Leider gibt es darüber keinen Konsens und wird es zumindest in den kommenden Jahren keinen geben.

KURZE ANTWORT

Verwenden Sie das, was die Software, mit der Sie arbeiten, als Eingabe akzeptiert. Für Ihre eigenen Projekte können Sie natürlich Ihre Vorlieben haben und sich daran halten.

---

Beachten Sie, dass verschiedene Betriebssysteme eine Dateierweiterung auf unterschiedliche Weise behandeln. Auf einigen ist es völlig in Ordnung, config.yml und config.yaml nebeneinander zu haben, auf anderen nicht.

Ich bin kürzlich auf eine lustige Situation gestoßen, die mich zu dieser Diskussion hier gebracht hat (eine von vielen :D). Diese Geschichte wird zeigen, dass Aussagen wie "YAML/YML ist das offizielle, weil die Google-Suche mehr Ergebnisse für YAML/YML liefert" nicht nur ungültig sind (meistens wegen der Realität und der Tatsache, dass die Suche nach YAML Ergebnisse liefert, die möglicherweise gar nicht die Dateierweiterung erwähnen, sondern eher die Sprache selbst behandeln!), sondern auch gefährlich sind und die kostbare Zeit eines Entwicklers immer wieder verschwenden können.

---

DIE GESCHICHTE

Ich hatte eine CICD-Pipeline mit einem Bereitstellungsabschnitt eingerichtet, der Helm verwendet, um das Bild abzurufen, das ich in einem früheren Abschnitt erstellt hatte, es auf meinem Kubernetes-Cluster bereitzustellen und einen Dienst dafür zu erstellen. All dies diente nur dazu, zu erkunden, wie Kubernetes funktioniert und was CICD bedeutet. Ich habe mir ein leeres Repository erstellt und bin sofort zum Web-Editor in GitLab gegangen, um die CICD-Konfigurationsdatei zu bearbeiten. Wenn keine vorhanden ist (im Fall der Erstellung eines leeren Repositorys) wird Ihnen ein Button wie dieser angeboten:

Was dies tut, ist eine Beispieldatei .gitlab-ci.yml im Stammverzeichnis Ihres Repositorys zu erstellen, wo der CICD-Mechanismus von GitLab nach seiner Konfiguration sucht.

Ein paar Tage später war ich dabei, Helm einzurichten. Ohne nachzudenken, erstellte ich alle mit dem Helm-Chart zusammenhängenden Dateien (Chart, values, deployment-Vorlage usw.).

Das Ausführen der Pipeline (eine völlig gültige und einfache) zeigte seltsames Verhalten. Ich erhielt einen Fehler, dass Charts.yaml nicht gefunden werden konnte. Ich überprüfte. Es war da. Es dauerte eine Weile, bis ich herausfand, dass Helm nach YAML und nicht nach YML suchte. Ein weiterer Versuch nach Umbenennung der Datei ergab einen seltsamen Fehler, dass ein Wert irgendeiner Art nicht gefunden werden konnte. Lustigerweise war es der erste Wert, auf den ich in meiner Bereitstellungsdatei verwies. Und das lag daran, dass es YML und nicht YAML war.

Also, um die Dinge konsistent zu halten (wer mag schon eine Menge Dateien für dieselbe Sprache mit unterschiedlichen Dateierweiterungen im selben Repository haben?) beschloss ich, .gitlab-ci.yml in .gitlab-ci.yaml umzubenennen. Das war der letzte Commit, den ich an diesem Abend gemacht habe. Am nächsten Tag rief ich einen Kollegen an und erzählte ihm, dass ich etwas eingerichtet hätte, das auch für ihn nützlich sein könnte und ob er es sich ansehen möchte. Ein Treffen wurde vereinbart und ich fuhr fort, etwas anderes zu tun.

Während des Meetings sagte ich ihm, dass ich gerade etwas committen werde (ich habe meinen Bildschirm geteilt) in die Flask-App, die ich als Versuchskaninchen erstellt habe (eine Hello World App im Grunde genommen), und er könne sich mit meinem Cluster über IP und Port XYZ verbinden, um die Änderungen zu sehen. Wir waren beide aufgeregt. Ich habe committet, meine Änderungen in das entfernte Repository gepusht und gewartet... und gewartet... Zu einem bestimmten Zeitpunkt fragte mich mein Kollege, ob er etwas verpasst hätte. Ich sagte nein, er sollte die Änderungen bereits sehen können. Aber es gab keine. Das Commit war vorhanden (sowohl lokale als auch entfernte Historie zeigten es), aber die Pipeline des entfernten Repositorys wurde nicht ausgelöst, es wurden keine Aufträge ausgeführt und kein Upgrade des Bildes und der Bereitstellung durchgeführt. Das Treffen war vorbei.

Dauerte eine halbe Stunde, um das Problem zu finden. GitLab mag kein .yaml für die .gitlab-ci-Datei. Es erkennt nur .yml. Das habe ich herausgefunden, indem ich zum Web-Editor gegangen bin und versucht habe, die Pipeline dort zu bearbeiten, nur um vom Button begrüßt zu werden, den ich oben gepostet habe. Ich beschloss dann, darauf zu klicken und einfach meine alte Pipeline zu kopieren und einzufügen. Es hat funktioniert. Aber jetzt hatte ich sowohl .gitlab-ci.yml als auch .gitlab-ci.yaml im Stammverzeichnis des Repositorys. Nur die .yml-Version funktionierte natürlich.

---

Ich habe mehrere Diskussionen wie diese sowohl auf GitLab als auch auf Helm besucht, um zu sehen, ob nur ich von diesem Verhalten genervt bin. Eines, das in der Helm GitHub-Issue zu diesem Thema herausgestellt wurde, war, dass, wenn Sie eine YAML- und eine YML-Datei haben, welche sollte eine höhere Priorität haben? Ich habe das auf GitLab gepostet (natürlich dasselbe Problem dort :D) und darauf hingewiesen, dass dies eine ganz neue Debatte eröffnen würde, bei der die Leute darüber streiten würden, ob YAML oder YML genommen werden sollte, wenn beide vorhanden sind und damit ein Huhn-und-Ei-Problem schaffen.