Ease consumption by means of .tool-versions

[paulo-ferraz-oliveira]

This allows using a .tool-versions file as per asdf constraints.

The README.md changes should make the content of the pull request explicit.

---

Edit

This is working as expected as can be seen for example repo (link to .tool-versions):

• here: success / versions installed as per .tool-versions,
• here: error / version-type =/= strict
• and here: error / colliding inputs

---

Closes #137.

[paulo-ferraz-oliveira]

Not specific to this pull request, but was missing.

[paulo-ferraz-oliveira]

This is checked by code, in any case

[paulo-ferraz-oliveira]

Moving to Review-ready.

@kevinlang

[wojtekmach]

I'm personally not a fan of projects that commit .tool-versions as they would overwrite my global Elixir version choice. We wouldn't be able to easily support a valid asdf config like: elixir: 1.14.2-otp-25. I'm personally -1 on adding this but I don't have a strong opinion. For people who are checking in the versions file, it is not easy to parse and fill in the setup-beam version values in the workflow, so this change is definitely very convenient.

[wojtekmach]

I understand the rationale but I think it would be more convenient if we didn't have to specify version-type if version-file is set. (we'd fail if it is set to something else than strict though.) Not a strong opinion.

[starbelly]

Are there actually cases where people put their .tool-versions deeper in their project? I think convention over configuration would indeed be better here, and then you provide a boolean. versions-from-file: true or something like that.

[paulo-ferraz-oliveira]

version-type is loose by default, so not specifying it is the same as choosing non-strict. I guess validating, in that case, unless it is strict, would always fail (?).

There is, however, a note on the README for this, so it'll fail at most once on your first run, where you include the new option. This seems safe.

@starbelly, as for a new option alongside a new option, I don't understand the rationale.

Are there actually cases where people put their .tool-versions deeper in their project?

It wouldn't matter, because the action reads a path, so you can put it wherever you want. The fact I named it like that, taking into account the issue that gave origin to this pull request, is that we might support more conventions in the future. If we think we won't, we should just change the option name to parse-tool-versions and use a default as you propose.

[starbelly]

@paulo-ferraz-oliveira Eh, it's not really a big deal IMO. I think the way you have it is more flexible, what I just suggested would result in almost the same amount of typing 😁

[starbelly]

I'm personally not a fan of projects that commit .tool-versions as they would overwrite my global Elixir version choice. We wouldn't be able to easily support a valid asdf config like: elixir: 1.14.2-otp-25. I'm personally -1 on adding this but I don't have a strong opinion. For people who are checking in the versions file, it is not easy to parse and fill in the setup-beam version values in the workflow, so this change is definitely very convenient.

I'm with you here, I see this as mostly useful for private applications myself. Not too many libs out in the wild using .tool-versions AFAIK.

[paulo-ferraz-oliveira]

From what you wrote, I have a feeling it doesn't hurt, but none of you are inclined to accept it, is that it, @starbelly, @wojtekmach? I guess if that's the case we need a better discussion workflow. 😄 There was an issue around this, and the idea wasn't reject by anyone. I later wrote I'd start to implement it, and I was apparently encouraged, but I might have over-read it, or under-reading what you wrote here.

I don't mind closing this pull request and moving forward, but I would like more concrete opinions on whether we keep it or drop it. 👍

[kevinlang]

I think having .tools-versions checked into the project is mainly beneficial for private applications, as @starbelly noted. I don't think disliking the default ASDF behavior of respecting repository-local .tools-versions files is a sufficient reason for excluding this feature. If one does not like that ASDF behavior, the solution is to configure their ASDF to not respect repository-local .tools-versions file. This can be done as outlined in this comment

[wojtekmach]

Sorry I wasn't clear. I personally wouldn't add it for the reason mentioned. But I'm not opposed to adding it. Does that make sense?

[paulo-ferraz-oliveira]

Sorry I wasn't clear. I personally wouldn't add it for the reason mentioned. But I'm not opposed to adding it. Does that make sense?

It does, thanks :)

[paulo-ferraz-oliveira]

And I know there might be this tendency to say "but it's optional", etc., but options have to be maintained too, so I do understand the rationale behind your rationale. (and also that we might run into issues regarding proper parsing of the tools file).

[starbelly]

I just wanted to say great job on this @paulo-ferraz-oliveira , there's a lot of teams that will get a lot of mileage out of it! ❤️

[paulo-ferraz-oliveira]

I'm going to check further on how the file is parsed by asdf (I only did it by trying, for this implementation, initially) and replicate it. The magic happens here (strip comments) and here (parse file).