[feature] Support .yaml extension for configuration files
andrewthauer opened this issue · comments
Is your feature request related to a problem? Please describe.
Yaml unfortunately does not have a consistent file extension. Either .yml or .yaml are accepted. Some languages or tools prefer one or the other or both. Having a repo with a mixed set of .yaml and .yml becomes a little confusing and less clear when to use one extension or the other. It's quite common for tools to actually look for both extensions by default for this reason.
Describe the solution you'd like
I am able to use the .yaml extension on all moon repo configuration files (e.g. ./moon/workspace.yaml, .moon/tasks.yaml, moon.yaml, etc.
Describe alternatives you've considered
It could be a configuration setting, but then the question of where and how to set this becomes a concern. I think this seems most reasonable to just look for both.
Additional context
We chose .yml as the extension for everything, as that's what a lot of other tools also use, like GitHub and Yarn.
We don't support both patterns as we would need to double the amount of file look ups, and rework a ton of globbing/hashing logic. However, it should warn you when using the wrong extension.
I personally want to move away from YAML, but there's no better alternatives right now.
We chose .yml as the extension for everything, as that's what a lot of other tools also use, like GitHub and Yarn.
Fair enough, but even. Interestingly GitHub Action workflows will accept both .yml or .yaml as well.
We chose .yml as the extension for everything, as that's what a lot of other tools also use, like GitHub and Yarn.
Would you be open supporting environment variable(s) to control this behaviour instead?
I personally want to move away from YAML, but there's no better alternatives right now.
I have no love for YAML either. I've already found expressing certain things for moon in YAML a little limiting already. At least initially to figure out. That said, I've gotten most of my current use cases working without being overly verbose either. Definitely familiar to use, but I'd welcome something else.
Lately been using cue more and more, and find it very refreshing and powerful when compared to YAML. It's definitely an option to consider imo. Looks like a lot of the larger build systems like Bazel, Buck, etc. are using Starlark, but I haven't done anything with that as a comparison.
We chose
.ymlas the extension for everything, as that's what a lot of other tools also use, like GitHub and Yarn.We don't support both patterns as we would need to double the amount of file look ups, and rework a ton of globbing/hashing logic. However, it should warn you when using the wrong extension.
I personally want to move away from YAML, but there's no better alternatives right now.
Have you thought about being able to configure moon using actual programming languages?
Lately been using cue more and more, and find it very refreshing and powerful when compared to YAML. It's definitely an option to consider imo. Looks like a lot of the larger build systems like Bazel, Buck, etc. are using
Starlark, but I haven't done anything with that as a comparison.
Starlark isn't much better because a lack of static type checking.
Using a programming language would require either embedded it in moon, or requiring it to exist in the environment. It would also add a ton of overhead having to call out to it, which would defeat the purpose of using Rust :/
I've had a lot of ideas for writing a new config format, but Pkl just came out with most of my ideas: https://pkl-lang.org/blog/introducing-pkl.html Hate the name and some of the syntax though.
Cuelang already have a WASM build they use in their online playground and are working on WASM extensions that will let you create custom functions etc. in any language (i.e. rust). Since moon is already leveraging exercism for similar, this might be a good match.
As for Pkl, I'm less jazzed about it. It looks nice from a language perspective and seems intriguing. However, given how new it is, I think it has a fair bit of catch up to do. The really nice thing about cue is it's ability to interoperate with existing configuration languages and API schemas. Very useful when wrangling together a bunch of diverse toolchains of configuration etc.
Using a programming language would require either embedded it in moon, or requiring it to exist in the environment. It would also add a ton of overhead having to call out to it, which would defeat the purpose of using Rust :/
Not if it's WASM.
Herein lies the problem that WASM has to built first though.
Since we are getting a little off topic from the original issue intent ...
Is the any appetite to support either changing/using a different yaml file extension? Either through some config, environment variable, or looking for both extensions?
If not, I'm happy to close the issue as won't do. That said, I still think it's not ideal to support both extensions in same shape or form. However, it's not a huge deal relative to other things.
I'd have to look into how much work it would take to support both. The .yml is pretty prevalent everywhere.
Here's a rough impl: #1377
I'm not sure I like this. It doubles fs calls and some conditionals, and it simply adds another layer in which bugs get introduced, if a conditional forgot to support both patterns.
Here's a rough impl: #1377
Thanks for looking into supporting this. Yeah, based on the current approach, I can see this being a bit problematic from a maintenance perspective.
To support this in a more sustainable way, I suspect some additional refactoring would be required to centralize the lookup logic more. I'm pretty new to rust and this codebase, so I don't have any initial great ideas for this atm.
A potential benefit of centralizing path/dir lookup logic would help support other common conventions being used now. For example, it's becoming quite common to use .config/my-tool to avoid cluttering a projects root with dotfiles/dotdirs. This is related to the commonly respected XDG Spec (e.g. ~/.config/my-tool, ~/.local/bin/my-tool, ~/.cache/my-tool, etc.) as well.
Decided against this since it adds a lot of overhead. I'd rather focus on moving to something else besides YAML.
Decided against this since it adds a lot of overhead. I'd rather focus on moving to something else besides YAML.
@milesj - Is there an issue I can follow regarding alternative code based configuration?
There is not, it's just top of mind. Especially since YAML support in rust is pretty much unmaintained.