Closed mogest closed 5 months ago
👋
Back when we introduced support for .tool-versions
our goal was already to try and prepare for future files, which is why you specify version-file
- hoping one version file has a given known format, too - like the one you mention.
A pull request to support the [tools]
section of that file is welcome 🎉 - within the implemented restrictions (e.g. one version per tool, for example). It does require, though, that we don't break existing consumers, so we need to add a version-file-type
input, with asdf
being the default (and in case it's not specified we warn about, using GHA's appropriate functions, but don't error out).
So:
version-file-type: asdf | mise
(asdf
being the default)version-file-type
is not specified we warn about it, so consumers can "fix" their inputI don't mind reviewing a draft pull request to get you going, or continuing the discussion here before you move to it. 👍
Detail: unlike .tool-versions
, TOML is a "known" config. format, so it's probably best to look at using an existing JS parser instead of doing it like we did 😄
Thanks @paulo-ferraz-oliveira! The one question I was going to ask was whether to hand-roll the parsing or using a toml library, and you've already answered it 🚀
I'll give it a bash over the next few days.
Related pull request was closed as state
. This issue will be too. If there's further interest we can think about continuing the pull request or re-opening this.
Currently, setup-beam supports asdf's
.tool-versions
file.A similar tool that is increasing in popularity is mise, previously known as rtx but recently renamed because of the naming conflict with NVIDIA's RTX graphics cards.
mise uses a
.mise.toml
file which fulfils a similar role to.tool-versions
. Here's an example of what one looks like:I'm happy to write a PR to support mise, but wanted to check in with the maintainers to see that it would be a valuable and accepted contribution first.