¿Es .yaml o .yml?

Según yaml.org , la extensión oficial del archivo es .yaml.

Citar:

¿Existe una extensión oficial para los archivos YAML?

Utilice ".yaml" cuando sea posible.

Sin embargo, parece haber un desacuerdo en Internet sobre qué extensión usar. Si busca ejemplos en la web , muchos de ellos usan la .ymlextensión no autorizada .

Buscar en Google arroja casi 3 veces más resultados para el más corto.

49,100

15,400

Entonces, ¿qué se supone que debo usar? ¿La extensión adecuada de 4 letras sugerida por el creador, o la extensión de 3 letras encontrada en el salvaje oeste de Internet?

La naturaleza e incluso la existencia de extensiones de archivo dependen de la plataforma (algunas plataformas oscuras ni siquiera las tienen, recuerde); en otros sistemas son solo convencionales (UNIX y sus características), mientras que en otros tienen una semántica definida y, en algunos casos, límites específicos de longitud o contenido de caracteres (Windows, etc.).

Dado que los encargados del mantenimiento le han pedido que use ".yaml", eso es lo más cercano a una decisión "oficial" que puede obtener, pero es difícil dejar el hábito de 8.3 (y, atrozmente, todavía es ocasionalmente relevante en 2013).

EDITAR:

Entonces, ¿qué se supone que debo usar? ¿La extensión adecuada de 4 letras sugerida por el creador, o la extensión de 3 letras encontrada en el salvaje oeste de Internet?

Esta pregunta podría ser:

1. Una solicitud de asesoramiento; o

2. Una expresión natural de esa emoción particular que se experimenta, mientras uno observa que se están ignorando algunas recomendaciones oficiales, de manera prominente, o incluso predominantemente.

Las personas difieren en su predilección por lo siguiente:

1. Consejo oficial o

2. La preponderancia de la práctica.

Por supuesto, es poco probable que influya en usted, en cuanto a cuál de estos dos caminos prefiere tomar!

En lo que sigue (y, en el espíritu de la ciencia), simplemente hago una hipótesis sobre qué (simplemente como cuestión de hecho) llevó a la mayoría de las personas a usar la extensión de 3 letras. Y me enfoco en causas eficientes.

Por esto, no pretendo exhortar moralmente. Como recordarán, el hecho de que algo es, no implica que deba serlo.

Cualquiera que sea su inclinación personal, ya sea para seguir un camino u otro, no me opongo.

(Fin de la edición).

La sugerencia de que esta preferencia (en el uso de la vida real) fue causada por una limitación DOS-ish de 8.3 caracteres, IMO es una pista falsa (errónea y engañosa).

A partir de agosto de 2016, los recuentos de búsqueda de Google para YML y YAML fueron de aproximadamente 6,000,000 y 4,100,000 (con dos dígitos de precisión). Además, el recuento de "YAML" fue injustamente alto porque incluía la mención del idioma por su nombre, más allá de su uso como extensión.

A partir de julio de 2018, los recuentos de búsqueda de Google para el YML y YAML fueron aproximadamente 8.100.000 y 4.100.000 (de nuevo, a dos dígitos de precisión). Entonces, en los últimos dos años, YML esencialmente ha duplicado su popularidad, pero YAML se ha mantenido igual.

Otra medida cultural son los sitios web que intentan explicar las extensiones de archivo. Por ejemplo, en el sitio web de FilExt (a partir de julio de 2018), la página de YAML da como resultado: "¡Vaya! La base de datos de FILEXT.com no tiene ninguna información sobre la extensión de archivo .YAML".

Mientras que, tiene una entrada para YML , que da: "YAML ... usa un archivo de texto y lo organiza en un formato que es legible para humanos. 'Database.yml' es un ejemplo típico cuando Ruby on Rails usa YAML para conectarse a una base de datos ".

A partir de noviembre de 2014, el artículo de Wikipedia sobre la extensión YML todavía decía que ".yml" es " la extensión de archivo para el formato de archivo YAML" (énfasis agregado). Su artículo de YAML enumera ambas extensiones, sin expresar una preferencia.

La extensión ".yml" es suficientemente clara, es más breve (por lo tanto, más fácil de escribir y reconocer) y es mucho más común.

Por supuesto, ambas extensiones podrían verse como abreviaturas de una extensión larga y posible, ".yamlaintmarkuplanguage". ¡Pero los programadores (y los usuarios) no quieren escribir todo eso!

En cambio, los programadores (y los usuarios) queremos escribir lo menos posible, y aún así ser inequívocos y claros. Y queremos ver qué tipo de archivo es, lo más rápido posible, sin leer una palabra más larga. Escribiendo cuántos personajes cumple estos dos objetivos? ¿No es la respuesta tres (3)? En otras palabras, ¿YML?

La página de la categoría Wikipedia : Filename_extensions enumera entradas para .a , .o y .Z . De alguna manera, se perdió .c y .h (utilizado por el lenguaje C). Estos ejemplos de extensiones de una letra nos ayudan a ver que las extensiones deberían ser tan largas como sea necesario, pero no más (para comillas medias de Albert Einstein).

En cambio, observe que, en general, algunas extensiones comienzan con "Y". Comúnmente, por otro lado, la letra X se usa para una gran variedad de significados, incluyendo "cruz", "extensible", "extremo", "variable", etc. (por ejemplo, en XML). Entonces, comenzar con "Y" ya transmite mucha información (en términos de teoría de la información), mientras que comenzar con "X" no lo hace.

Lingüísticamente hablando, por lo tanto, el acrónimo "XML" tiene (en cierta forma) solo dos letras informativas ("M" y "L"). "YML", en cambio, tiene tres letras informativas ("M", "L" e "Y"). De hecho, el conjunto existente de siglas que comienzan con Y parece extremadamente pequeño. Por implicación, esta es la razón por la cual una extensión de archivo YAML de cuatro letras se siente muy sobreespecificada.

Quizás es por eso que vemos en la práctica que la presión "lingüística" (en uso natural) para alargar la abreviatura en cuestión a cuatro (4) caracteres es débil, y la presión "lingüística" para acortar esta abreviatura a tres (3) caracteres es fuerte.

Simplemente como resultado, probablemente, de estos factores (y no como un respaldo oficial), quisiera señalar que la última noticia del sitio web de YAML.org (desde noviembre de 2011) se trata de un proyecto escrito en JavaScript, JS-YAML , que, internamente, prefiere usar la extensión ".yml".

Los factores mencionados anteriormente pueden haber sido los principales; sin embargo, todos los factores (conocidos o desconocidos) han dado como resultado que la extensión abreviada de tres (3) caracteres se convierta en la de uso predominante para YAML, a pesar de la preferencia de los inventores.

".YML" parece ser el estándar de facto . Sin embargo, los mismos inventores fueron perceptivos y correctos, sobre la necesidad del mundo de un lenguaje de datos legible por humanos. Y deberíamos agradecerles por proporcionarlo.

Después de leer un montón de comentarios de personas en línea sobre esto, mi primera reacción fue que este es básicamente uno de esos debates realmente sin importancia. Sin embargo, mi interés inicial era encontrar el formato correcto para poder ser coherente con mi práctica de denominación de archivos.

En pocas palabras, el creador de YAML dice .yaml, pero personalmente sigo haciéndolo .yml. Eso solo tiene más sentido para mí . Así que emprendí el viaje para encontrar afirmación y muy pronto me di cuenta de que Docker usa en .ymltodas partes. He estado escribiendo docker-compose.ymlarchivos todo este tiempo, mientras sigues viendo en los documentos de Kubernetes kubectl apply -f *.yaml...

Entonces, en conclusión, ambos formatos son obviamente aceptados y si está en el otro extremo (es decir, sistemas de escritura que reciben un archivo YAML como entrada) debe permitir ambos. Eso parece otro caso de serpiente versus cosa de camello ...

.yamlaparentemente es la extensión oficial, porque algunas aplicaciones fallan al usarlas .yml. Por otro lado, no estoy familiarizado con ninguna aplicación que use código YAML, pero falla con una .yamlextensión.

Me topé con esto, ya que estaba acostumbrado a escribir .ymlen Ansible y Docker Compose. Por costumbre, solía .ymlescribir archivos de Netplan que fallaban en silencio. Finalmente descubrí mi error. El autor de un papel popular de Ansible Galaxy para Netplan hace la misma suposición en su código:

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

Sin embargo, .ymlNetplan ignora los archivos con una extensión de la misma manera que los archivos con una .bakextensión. Como Netplan es muy silencioso y no ofrece comentarios sobre el éxito, incluso con netplan apply --debuguna configuración como la 01-netcfg.ymlque fallará en silencio sin ningún comentario significativo.