Many projects already have YAML files in their tree that use the .yml extension. Such examples include .travis-ci.yml. When adding Snap support to these existing projects it gets confusing when to use .yml vs .yaml. Snapcraft should, therefore, accept both .yaml and .yml as the snapcraft.yaml file extension. This will make things more aesthetically pleasing, especially for cases where you’re placing a .snapcraft.yaml alongside other CI tools like .travis-ci.yml.
Snapcraft shoud accept:
snap/snapcraft.yaml
snap/snapcraft.yml
.snapcraft.yaml
.snapcraft.yml
The build service should also be updated to support these new extensions.
Please don’t. Increasing the number of possible locations is a pain: due to things like base: and architectures:, Launchpad needs to inspect snapcraft.yaml in order to work out which builds to dispatch in what environments before it can even get as far as running Snapcraft. For trees that are hosted on Launchpad this is only a mild annoyance; for trees that are hosted on GitHub it involves more requests to check more possible locations, and we run the risk of exceeding rate limits. And of course there are the usual problems associated with adding more things that multiple bits of software need to check, such as busywork for the maintainers of those programs, and increased potential for them to disagree.
Each of the existing paths had something resembling a functional justification: I initially pushed back on build-aux/snap/snapcraft.yaml until it became clear that there were tree-layout issues in some projects that were difficult to solve without introducing it. But this proposal has only aesthetic justification, and I don’t think that’s enough to justify the increased operational costs.
