5 ms·

It is customizable: > 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 ca

by sigg3 3y ago

It is customizable: > 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.

timmytokyo 3y ago
It's customizable, but it downloads by default. Anyone who cares about controlling what they download from the Internet would prefer opt-in, not opt-out.
- bushbaba 3y ago
  Tend to agree here. Feels like an overstep
- codazoda 3y ago
  I’m a veteran dev but I’m new to Go… 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. Ref: https://go.dev/doc/toolchain https://go.dev/doc/toolchain
- silisili 3y ago
  Seems crazy to me. I want to see an error if the version in my PATH is too old, so I can address. I don't want my toolchain to do -anything- implicitly, including searching PATH. If my PATH is wrong, I'll fix it. 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?
- maccard 3y ago
  And people who don't care won't change the default settings. 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.
ilyt 3y ago
That's terrible default. 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
sidewndr46 3y ago
This is going to be hilarious when every docker container starts updating itself on every single invocation!

by sigg3 3y ago

timmytokyo 3y ago

It's customizable, but it downloads by default. Anyone who cares about controlling what they download from the Internet would prefer opt-in, not opt-out.

bushbaba 3y ago
Tend to agree here. Feels like an overstep
codazoda 3y ago
I’m a veteran dev but I’m new to Go… 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. Ref: https://go.dev/doc/toolchain https://go.dev/doc/toolchain
silisili 3y ago
Seems crazy to me. I want to see an error if the version in my PATH is too old, so I can address. I don't want my toolchain to do -anything- implicitly, including searching PATH. If my PATH is wrong, I'll fix it. 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?
maccard 3y ago
And people who don't care won't change the default settings. 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.

ilyt 3y ago

That's terrible default. 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

sidewndr46 3y ago

This is going to be hilarious when every docker container starts updating itself on every single invocation!