Enforce .yaml extension and ban .yml

[vlotorev]

According to YAML FAQ [1] .yaml is the only official extension for YAML files.

[1] https://yaml.org/faq.html

[davedittrich]

The proposal doesn't provide any cost/benefit analysis, and switching to requiring files only end in .yaml in order to be processed is going to have a HUGE impact on many users.

All of the Ansible documentation, Stackexchange posts, and Medium articles that currently contain .yml file names will remain in search engines for years and cause confusion in users who accidentally find them. The pace of change in Ansible products already causes this "cached search results" problem for users that introduces a lot of friction and frustration. If RedHat would add meta tags to the Ansible documentation pages that down-rank older results, that would help (but that still leaves those other sites providing old information). This kind of a change, if mandatory, is a breaking change when it comes to older examples and open source repos.

The YAML FAQ (which even says "when possible") simply states a preference, but that preference has no quantifiable beneficial impact I can think of related to linting if implemented. It is pretty trivial to get the file extension with pathlib, lowercase it, and compare ext in ['.yml', '.yaml'] and get on to validating content. Or use a function call to be more DRY, if that is the unstated reason for the proposal.

Can you explain what benefits this change brings to users that outweighs the costs?

[vlotorev]

The proposal doesn't provide any cost/benefit analysis, and switching to requiring files only end in .yaml in order to be processed is going to have a HUGE impact on many users.

Rules can be disabled/enabled per projects, so users have a choice if they are impacted.

All of the Ansible documentation, Stackexchange posts, and Medium articles that currently contain .yml file names will remain in search engines for years and cause confusion in users who accidentally find them.

I don't see how reasoning about examples in internet should stop implementing rules. There are surely a lot of misformatted YAML snippets (even Ansible documentation suffers from using different formatting in the same page, e.g. playbook_tests) out there but it didn't stop ansible-lint from enforcing yamllint rules.
Projects that use ansible-lint care about code quality and '.yml' files (as well as misformatted code) just will not hit those repos.

Can you explain what benefits this change brings to users that outweighs the costs?

Using both '.yaml' and '.yml' in the same documentation/project makes the reader's brain constantly stumble (like typos) and distracts attention.

Using one extension in the project, across the projects/teams reduces code review cycles and discussion.

---

Fair enough ansible related projects tend to prefer 'yml' instead of 'yaml':

$ find ansible-lint -name '*.yaml' | wc -l
26
$ find ansible-lint -name '*.yml' | wc -l
440
$ grep -R \\.yaml ansible-lint/docs/ | wc -l
15
$ grep -R \\.yml ansible-lint/docs/ | wc -l
45

$ find ansible -name '*.yaml' | wc -l
90
$ find ansible -name '*.yml' | wc -l
1751
$ grep -R \\.yaml ansible/docs | wc -l
185
$ grep -R \\.yml ansible/docs | wc -l
949

The proportion of '.yaml'/'.yml' mentioning in Ansible documentation is more than the quantity of '.yaml'/'.yml' files in Ansible repo (185/949=~20% vs 90/1751=~5%). So devs want to write about '.yaml' files more than actually create 'yml' files in the repo.

Now seeing how deep Ansible devs in 'yml' indeed it's hardly can be changed to '.yaml' (ever). I withdraw my proposal.

[bbaassssiiee]

In many projects we have use-cases to distinguish Ansible files from other domain specific languages. Editors could be configured to recognize the difference based on the .yml or .yaml extension.