Est-ce .yaml ou .yml?

Selon yaml.org , l'extension de fichier officielle est .yaml.

Citation:

Existe-t-il une extension officielle pour les fichiers YAML?

Veuillez utiliser ".yaml" lorsque cela est possible.

Cependant, il semble y avoir un désaccord sur Internet sur l'extension à utiliser. Si vous recherchez des exemples sur le Web , beaucoup d'entre eux utilisent l' .ymlextension non autorisée .

La recherche Google renvoie près de 3 fois plus de résultats pour le plus court.

49,100

15 400

Alors, que suis-je censé utiliser? L'extension appropriée à 4 lettres suggérée par le créateur, ou l'extension à 3 lettres trouvée dans l'ouest sauvage d'Internet?

La nature et même l'existence des extensions de fichier dépend de la plate-forme (certaines plates-formes obscures n'en ont même pas, rappelez-vous) - dans d'autres systèmes, elles ne sont que conventionnelles (UNIX et ses semblables), tandis que dans d'autres encore, elles ont une sémantique définie et dans certains cas, des limites spécifiques sur la longueur ou le contenu des caractères (Windows, etc.).

Étant donné que les responsables ont demandé que vous utilisiez ".yaml", c'est aussi proche que possible d'une décision "officielle", mais il est difficile de se débarrasser de l'habitude de 8.3 (et, ce qui est horrible, est parfois pertinent en 2013).

ÉDITER:

Alors, que suis-je censé utiliser? L'extension appropriée à 4 lettres suggérée par le créateur, ou l'extension à 3 lettres trouvée dans l'ouest sauvage d'Internet?

Cette question pourrait être:

1. Une demande de conseil; ou

2. Une expression naturelle de cette émotion particulière qui est vécue, tandis que l'on observe que certaines recommandations officielles ne sont pas prises en compte, de manière importante, voire prédominante.

Les gens diffèrent dans leur prédilection pour ce qui suit:

1. Conseils officiels; ou

2. La prépondérance de la pratique.

Bien sûr, il est peu probable que je vous influence, sur lequel de ces deux chemins vous préférez emprunter!

Dans ce qui suit (et, dans l'esprit de la science), je fais simplement une hypothèse sur ce qui (simplement en fait) a conduit la majorité des gens à utiliser l'extension à 3 lettres. Et je me concentre sur des causes efficaces.

Par cela, je n'ai pas l'intention d'exhortation morale. Comme vous vous en souvenez peut-être, le fait que quelque chose soit, n'implique pas qu'il devrait l'être.

Quelle que soit votre inclination personnelle, que ce soit pour suivre un chemin ou l'autre, je ne m'y oppose pas.

(Fin de l'édition.)

La suggestion, que cette préférence (dans l'utilisation réelle) a été causée par une limitation DOS de 8,3 caractères, IMO est un hareng rouge (erroné et trompeur).

En août 2016, le nombre de recherches Google pour YML et YAML était d'environ 6 000 000 et 4 100 000 (avec deux chiffres de précision). En outre, le nombre de "YAML" était injustement élevé car il incluait la mention de la langue par son nom, au-delà de son utilisation comme extension.

En juillet 2018, le nombre de recherches de Google pour YML et YAML était d'environ 8,100,000 et 4,100,000 (encore une fois, avec deux chiffres de précision). Ainsi, au cours des deux dernières années, YML a essentiellement doublé de popularité, mais YAML est resté le même.

Une autre mesure culturelle est les sites Web qui tentent d'expliquer les extensions de fichier. Par exemple, sur le site Web FilExt (depuis juillet 2018), la page YAML se traduit par: "Oups! La base de données FILEXT.com ne contient aucune information sur l'extension de fichier .YAML."

Alors qu'il contient une entrée pour YML , qui donne: "YAML ... utilise un fichier texte et l'organise dans un format lisible par l'homme. 'Database.yml' est un exemple typique lorsque YAML est utilisé par Ruby on Rails pour se connecter à une base de données. "

En novembre 2014, l'article de Wikipedia sur l'extension YML indiquait toujours que ".yml" est " l' extension de fichier pour le format de fichier YAML" (non souligné dans l'original). Son article YAML répertorie les deux extensions, sans exprimer de préférence.

L'extension ".yml" est suffisamment claire, est plus brève (donc plus facile à taper et à reconnaître), et est beaucoup plus courante.

Bien entendu, ces deux extensions peuvent être considérées comme des abréviations d'une extension longue et possible, ".yamlaintmarkuplanguage". Mais les programmeurs (et les utilisateurs) ne veulent pas taper tout ça!

Au lieu de cela, nous, les programmeurs (et les utilisateurs), souhaitons taper le moins possible, tout en restant clairs et sans ambiguïté. Et nous voulons voir de quel type de fichier il s'agit, le plus rapidement possible, sans lire un mot plus long. Taper combien de personnages atteint ces deux objectifs? La réponse n'est-elle pas trois (3)? En d'autres termes, YML?

La page Catégorie de Wikipédia : extensions de nom de fichier répertorie les entrées pour .a , .o et .Z . D'une certaine manière, il manquait .c et .h (utilisé par le langage C). Ces exemples d'extensions d'une seule lettre nous aident à voir que les extensions doivent être aussi longues que nécessaire, mais pas plus (pour citer à moitié Albert Einstein).

Au lieu de cela, notez que, en général, peu d'extensions commencent par "Y". D'un autre côté, la lettre X est utilisée pour une grande variété de significations, y compris «croisé», «extensible», «extrême», «variable», etc. (par exemple en XML). Donc, commencer par "Y" véhicule déjà beaucoup d'informations (en termes de théorie de l'information), contrairement à commencer par "X".

Du point de vue linguistique, l'acronyme "XML" n'a donc (en quelque sorte) que deux lettres informatives ("M" et "L"). "YML", au lieu de cela, a trois lettres informatives ("M", "L" et "Y"). En effet, l'ensemble des acronymes existants commençant par Y semble extrêmement petit. Par implication, c'est pourquoi une extension de fichier YAML à quatre lettres semble considérablement sur-spécifiée.

C'est peut-être pour cela que l'on voit en pratique que la pression "linguistique" (en usage naturel) pour allonger l'abréviation en question à quatre (4) caractères est faible, et la pression "linguistique" pour raccourcir cette abréviation à trois (3) caractères est fort.

En raison, probablement, de ces facteurs (et non comme une approbation officielle), je voudrais noter que la dernière actualité du site Web YAML.org (de novembre 2011) concerne un projet écrit en JavaScript, JS-YAML , qui, lui-même, préfère en interne utiliser l'extension ".yml".

Les facteurs susmentionnés peuvent avoir été les principaux; néanmoins, tous les facteurs (connus ou inconnus) ont fait en sorte que l'extension abrégée à trois (3) caractères devienne celle qui prédomine pour YAML - malgré la préférence des inventeurs.

".YML" semble être la norme de facto . Pourtant, les mêmes inventeurs étaient perspicaces et corrects, quant au besoin du monde d'un langage de données lisible par l'homme. Et nous devons les remercier de l'avoir fourni.

Après avoir lu en ligne un tas de commentaires de gens à ce sujet, ma première réaction a été que c'est essentiellement l'un de ces débats vraiment sans importance. Cependant, mon intérêt initial était de trouver le bon format afin que je puisse être cohérent avec ma pratique de dénomination des fichiers.

Pour faire court, le créateur de YAML dit .yaml, mais personnellement, je continue .yml. Cela fait juste plus de sens pour moi . J'ai donc continué le voyage pour trouver une affirmation et assez vite, je me rends compte que le docker utilise .ymlpartout. J'ai écrit des docker-compose.ymlfichiers tout ce temps, pendant que vous continuez à voir dans les documents de kubernetes kubectl apply -f *.yaml...

Donc, en conclusion, les deux formats sont évidemment acceptés et si vous êtes à l'autre bout (c'est-à-dire: les systèmes d'écriture qui reçoivent un fichier YAML en entrée), vous devez autoriser les deux. Cela semble être une autre affaire de serpent contre une affaire de chameau ...

.yamlest apparemment l'extension officielle, car certaines applications échouent lors de l'utilisation .yml. D'un autre côté, je ne connais aucune application qui utilise du code YAML, mais échoue avec une .yamlextension.

Je suis juste tombé sur cela, car j'avais l'habitude d'écrire .ymldans Ansible et Docker Compose. Par habitude, j'ai utilisé .ymllors de l'écriture de fichiers Netplan qui ont échoué en silence. J'ai finalement compris mon erreur. L'auteur d'un rôle populaire Ansible Galaxy pour Netplan fait la même hypothèse dans son code:

- name: Capturing Existing Configurations
  find:
    paths: /etc/netplan
    patterns: "*.yml,*.yaml"
  register: _netplan_configs

Pourtant, tous les fichiers avec une .ymlextension sont ignorés par Netplan de la même manière que les fichiers avec une .bakextension. Comme Netplan est très silencieux et ne donne aucun retour sur le succès, même avec netplan apply --debug, une configuration telle que celle- 01-netcfg.ymlci échouera silencieusement sans aucun retour significatif.