asdf-community/asdf-golang

asdf-golang is not selecting the expected version using legacy_version_file

jabrown85 opened this issue · 5 comments

jabrown85 commented

Describe the bug
asdf-golang is not selecting the expected version using only a go.mod

To Reproduce

➜  cat go.mod
module github.com/asdf-golang/issue

go 1.14
➜  asdf current golang
golang          1.17            /Users/jesse.brown/dev/jabrown85/go-test/go.mod
➜  asdf list golang
  1.14
  1.16
  1.17
➜  cat ~/.asdfrc
legacy_version_file = yes%

I know legacy_version_file is being respected given the output from go-test asdf current golang, but it seems to be picking the latest matching major version.

Expected behavior
I would expect go-test asdf current golang and subsequently go version to produce 1.14

Desktop (please complete the following information):

  • OS: macOS 11.6
kennyp commented

Hey Jesse, the current behavior is actually what is intended based on how go.mod is described in the go docs.

For an exact version I would use a .tool-versions file.

myhro commented

Hi Kenny,

I'm trying to find a way to overcome this behavior - which I totally get the reasoning, but it's not working for my specific use case.

I'm using Go 1.18beta1 for a single project where I'm exploring its new features. The problem is that when there isn't a local .tool-versions on all the other repositories, it reads go 1.17 from go.mod and ends up selecting the 1.18beta1 one. This is not ideal, as golangci-lint is currently not working with the latter.

I've tried to use the minor/non-exact version format within .tool-versions, to avoid updating all repositories whenever a patch version is released, but that's not possible:

$ echo 'golang 1.17' > .tool-versions
$ go version
No preset version installed for command go
Please install a version by running one of the following:

asdf install golang 1.17

or add one of the following versions in your config file at /Users/myhro/Documents/github.com/myhro/feeds/.tool-versions
golang 1.17.5
golang 1.18beta1

The only workaround I found until now is to resort to the legacy version file, which supports the minor/non-exact version format:

$ rm .tool-versions
$ echo 'legacy_version_file = yes' > ~/.asdfrc
$ go version
go version go1.18beta1 darwin/amd64
$ echo '1.17' > .go-version
$ go version
go version go1.17.5 darwin/amd64

Which is also a bit cumbersome, given it's a legacy option.

Would it be possible to offer a configuration option to disable the default behavior of reading the version from go.mod? I've checked the PR #32 which introduced it, but looks like right now that's not optional.

Not going after non-stable versions would also work, but I'm not sure if that's compatible with the go directive meaning within go.mod. I haven't found any mentions to that in the official docs.

kennyp commented

Hey @myhro,

In your .tool-versions file if you use 1.17.5 based on the output you should be good.

There is an option to turn off the legacy version support in asdf. https://asdf-vm.com/manage/configuration.html#legacy-version-file

But then you would still need to set golfing 1.17.5 in your .tool-versions file.

myhro commented

Hi Kenny,

In your .tool-versions file if you use 1.17.5 based on the output you should be good.
(...)
But then you would still need to set golfing 1.17.5 in your .tool-versions file.

This exactly what I want to avoid. I would like to stick to whatever 1.17.x I have available, without specifying the minor release or the go.mod-based fallback sticking to the 1.18.x beta versions.

Currently, I can only do that by opting for the legacy version support.

kennyp commented