> Not everyone is going to be happy with the idea of the 'go' command downloading and running binaries from the Internet. If this is the case for you, you need to set GOTOOLCHAIN to either 'path', if you're happy to search $PATH for the right toolchain, or 'local', if you want to turn off this behavior entirely and have 'go' just fail.
The following quotes seem to indicate that “auto” is not the default. At least, not if you haven’t run some command to set it at a default (and I’m not seeing one).
> If the $GOROOT/go.env file is missing or does not set a default, the go command assumes GOTOOLCHAIN=local.
> When GOTOOLCHAIN is set to local, the go command always runs the bundled Go toolchain.
In the intro, however, it does say:
> The default GOTOOLCHAIN setting is auto, which enables the toolchain switching described earlier.
I guess I’m also confused. :/
Note that go.work is only created by the `go work init` command when you intend to use multiple modules in one directory. I’m guessing that doing this is relatively unusual. This could be how a “default” gets set for newer versions (unconfirmed conjecture on my part).
I don’t see any command that creates a `go.env` and therefore might set GOTOOLCHAIN in that file.
The only other thing I can think of is that `go mod init` could set this to “auto” in the `go.mod` of a new project. But, go.env is probably missing in this case.
And downloading is even weirder. What happens if the download fails? Am I presented a random network error, or a Go too old error? Who decides which is even more correct?
The best case scenario is opt-out. That way people who care have a choice, and people who don't care are updated. People will complain either way.
Reminds me on GOPRIVATE bullshit where since some go version private repositories outright didn't work without setting env variables, because go team decided to not add fallback if something is not available via their shitty proxy