Related Issues

• Test #67906 (closed)
• go build #52634 (closed)
• go #49423 (closed)
• cmd/go: Go modules initialised by go1.21.1 cannot be built using go1.20.8 #63279 (closed)
• cmd/go: build failed #59694 (closed)
• go #64466 (closed)
• test #43061 (closed)
• Bugs-Report #62338 (closed)
• Test #70447 (closed)
• run #70024 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

GOTOOLCHAIN='local

you've explicitly asked that go not upgrade the toolchain for you.

I don't think I did:

evcc chore/generate ≡
❯ go env -changed
evcc chore/generate ≡
❯ export | grep GOTOOL

So where does the local come from?

If I force it to auto this does not seem to be the default setting anymore:

evcc chore/generate ≡
❯ go env -w GOTOOLCHAIN=auto
evcc chore/generate ≡
❯ go env -changed
GOTOOLCHAIN='auto'

If local however is the default then it seems to defy the purpose if downloading newer toolchains.

According to https://go.dev/doc/toolchain:

In the standard configuration, the go command uses its own bundled toolchain when that toolchain is at least as new as the go or toolchain lines in the main module or workspace.

Since I have- afaikt- the standard configuration this is not what seems to be happening here.

check /opt/homebrew/Cellar/go/1.23.4/libexec/go.env

local seems to be the default in any case:

If the $GOROOT/go.env file is missing or does not set a default, the go command assumes GOTOOLCHAIN=local.

❯ cat /opt/homebrew/Cellar/go/1.23.4/libexec/go.env
# This file contains the initial defaults for go command configuration.
# Values set by 'go env -w' and written to the user's go/env file override these.
# The environment overrides everything else.

# Use the Go module mirror and checksum database by default.
# See https://proxy.golang.org for details.
GOPROXY=https://proxy.golang.org,direct
GOSUMDB=sum.golang.org

# Automatically download newer toolchains as directed by go.mod files.
# See https://go.dev/doc/toolchain for details.
GOTOOLCHAIN=local

Automatically download newer toolchains as directed by go.mod files.

Is not happening...

that appears to be a homebrew issue https://github.com/Homebrew/homebrew-core/blob/master/Formula/g/go.rb#L93

which deviates from upstream https://github.com/golang/go/blob/master/go.env

see this line in particular https://github.com/Homebrew/homebrew-core/blob/b7a91605ef0a48dac1726cd989b429b3b0ca99c3/Formula/g/go.rb#L66
there's not much we can do about homebrew not updating the comments to reflect their policy

Thank you, that clarifies it. However, it is still confusing that

go env -changed

doesn't show this as changed. Seems go env reports against go.env but not against Go standard config?

yes, "standard" is defined by what's in go.env, cmd/go doesn't have any other default.

see this line in particular Homebrew/homebrew-core@b7a9160/Formula/g/go.rb#L66 there's not much we can do about homebrew not updating the comments to reflect their policy

Setting GOTOOLCHAIN=local is documented whenever you [re]install/upgrade go using Homebrew:

❯ brew reinstall go
[snip]
==> Caveats
Homebrew's Go toolchain is configured with
  GOTOOLCHAIN=local
per Homebrew policy on tools that update themselves.
[snip]

But updating the comment in go.env is probably something we can do too.

cc @matloob @samthanawalla

I wonder if cmd/go should add a hint to go.mod parsing errors when the go line required a newer version, but GOTOOLCHAIN prevents an upgrade. We used to do something like this in the compiler IIRC.

I'm thinking something like:

go: errors parsing go.mod:
go.mod:206: unknown block type: tool
(Note: Out of date Go version? go.mod requires go1.24rc1, have go1.23.4, but GOTOOLCHAIN=local prevents upgrade)

Actually, come to think of it, even with GOTOOLCHAIN=local, due to forward compatibility, Go 1.23 would refuse to build this module even if go.mod did parse. So perhaps the real improvement here is just to move the version-based refusal earlier.