Go: don't set GOTOOLCHAIN=local

[andig]

brew gist-logs <formula> link OR brew config AND brew doctor output

❯ brew doctor
Your system is ready to brew.

Verification

• My brew doctor output says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.
• I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.

What were you trying to do (and why)?

Coming from golang/go#70949 where Go fails to install newer toolchain for compiling module. This is due to https://github.com/Homebrew/homebrew-core/blob/master/Formula/g/go.rb#L93. While this may be the right setting for compiling brew formulas, it breaks using Go for other purposes.

What happened (include all command output)?

go build

go: errors parsing go.mod:
go.mod:206: unknown block type: tool

What did you expect to happen?

Go 1.23 downloads Go 1.24 and compiles successfully.

Step-by-step reproduction instructions (by running brew commands)

n/a

[carlocab]

Does doing export GOTOOLCHAIN=auto not fix this for you?

[andig]

Yes it does (or rather, I've used go env -w GOTOOLCHAIN=auto). Would it make sense to apply the local only for building brew formulae but not for client builds? I.e. stick it in another place? It feels wrong to improve formula build constraints onto totally unrelated client builds.

[carlocab]

Per the caveats,

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

so formulae build constraints aren't really relevant here (even if you are correct to suggest that we do want GOTOOLCHAIN=local when building formulae).

[andig]

per Homebrew policy on tools that update themselves.

That refers to brew-installed tools? It doesn't seem to make much sense to impose this restriction on local dev work.

It feels (no pun intented!) that the real suggestion here it to use brew Go only as far as it's required for other formulas but switch to go.dev-downloaded go for local dev work.

[carlocab]

That refers to brew-installed tools?

Yes.

It feels (no pun intented!) that the real suggestion here it to use brew Go only as far as it's required for other formulas but switch to go.dev-downloaded go for local dev work.

You could do that. You could also configure GOTOOLCHAIN locally if local doesn't work for you. Not really sure why that's a huge impediment (and, indeed, a larger impediment than the effort of managing your own toolchains downloaded from go.dev).

[andig]

It isn't once you understand what's happening. It just seems to me that setting this locally also defeats the purpose of the original setting regarding self-updating tools. So it's really a no-op to have this in the first place?

[carlocab]

That argument holds only if every user of the Go formula sets GOTOOLCHAIN=auto locally. Do you have any evidence that this is the case?

[andig]

Obviously not. But if users do so to retain standard go behaviour it does. So imho it makes the use of it as part of the Go formula instead of the Go-dependent formulas brittle.

[carlocab]

In that case I'm not persuaded that it's a no-op.

It's certainly a no-op sometimes, if a user decides to override it. But it being sometimes a no-op is nowhere near as strong a reason to switch back to setting auto as it would be if it were always (or almost always) a no-op.

At this stage I'm not convinced we have good reasons to change this default given that:

1. it is clearly documented (in caveats, plus the misleading comment in go.env has now been removed)
2. it is trivial to override

But I'll tag @Homebrew/core here in case someone else has a different opinion.

[andig]

I don't have strong feelings either way now that I'm aware of it. I can imagine though that- although caveat documented- this may be overlooked by other users, too. If that can be prevented by enforcing the policy in a better way that would imho be preferred over unexpected changed to the Go standard.

Thanks for looking into this!

[MikeMcQuaid]

At this stage I'm not convinced we have good reasons to change this default given that:

1. it is clearly documented (in caveats, plus the misleading comment in go.env has now been removed)
2. it is trivial to override

I agree with this reasoning 👍🏻