Probably go env -w should apply any GOTOOLCHAIN changes to itself before exec'ing the GOTOOLCHAIN-based switch.

Marking as release-blocker for 1.21 because GOTOOLCHAIN is new in 1.21.

Probably go env -w should apply any GOTOOLCHAIN changes to itself before exec'ing the GOTOOLCHAIN-based switch.

Actually, I think that implies that you can't use go env -w to set a toolchain older than 1.21, since writing GOTOOLCHAIN into go.env guarantees that the file isn't compatible with a pre-1.21 toolchain. 🤔

@bcmills Won't the same sort of problem unfold any time a new variable gets added to go.env? For example, suppose Go 1.22 adds support for GOFOO.

$ go env -w GOFOO=bar
$ go env -w GOTOOLCHAIN=go1.21.0

Now everything will fail because 1.21 doesn't understand GOFOO, and I cannot fix it without manually editing the go.env file.

Even if go env -w prevented me from setting GOTOOLCHAIN in this case, it seems like this could lead to frustration going forward and ultimately undermine the utility of both GOTOOLCHAIN and go.env. Is there a reason the toolchain needs to fail on unrecognized entries instead of just ignoring them?

Is there a reason the toolchain needs to fail on unrecognized entries instead of just ignoring them?

go env -w certainly ought to do that to prevent typos, and I think the original reason for applying the same logic to the file was to detect erroneous hand-edits. But perhaps we should ignore unrecognized settings once they're already in the file.

But I don't see that that would help much for this particular case, because the same error will occur if you set GOTOOLCHAIN=1.18.10 and the 1.18 release is no longer receiving backports.

Re "I still cannot set to an empty value", the command does set it to an empty value. It just prints a warning that your environment is still going to override the value if you keep your environment that way.

Thinking out loud ...

There are a few cases here.

If you set GOTOOLCHAIN=garbage, then that will fail consistently, and you have to use GOTOOLCHAIN=local go env -w GOTOOLCHAIN=... to get back out.

If you set GOTOOLCHAIN=go1.19, that works fine for ordinary go commands, but you still have to use GOTOOLCHAIN=local go env -w GOTOOLCHAIN=... to get back out. That will stop being necessary once all the toolchains you care about know about go env -w GOTOOLCHAIN (when you stop caring about Go before Go 1.21).

If you have Go 1.21 and you set go env -w GOTOOLCHAIN=go1.22, then the next go env -w VAR_INTRODUCED_IN_GO1.22=... needs to use Go 1.22; we can't just make go env -w be forced to use the local toolchain.

Note that the go command already does ignore unrecognized settings in the file.

It seems like encouraging GOTOOLCHAIN=local as the workaround is the right answer today.

It's almost always a mistake to set go env -w GOTOOLCHAIN=go1.19 anyway (as opposed to setting a normal environment variable that way), so I'm not sure we have to worry too much about this case.

On the other hand, suppose for the sake of argument that we special case go env -w GOTOOLCHAIN=... to not invoke the known toolchain and just handle that one case itself. What could go wrong if we didn't invoke a newer toolchain for that? I suppose a newer toolchain might do some extra sanity checking of the GOTOOLCHAIN value, so we'd be cutting ourselves off from that. Maybe that's not enough of a compelling reason? Maybe we should add the special case?

Another option to consider is to allow only a couple of recognized values (e.g. local, auto??) for go env -w GOTOOLCHAIN=.... Even for go1.22, I cannot think of a valid case where setting this is desirable. Accidentally setting go env -w GOTOOLCHAIN=go1.20 will result in an unpleasant surprise when the user upgrades the local go version.

The only reason I encountered this issue was because I was messing with it to prototype an experimental idea. I ended up creating a special environment variable for the purpose.

@rsc any updates on this? This is currently marked as a release blocker and the freeze is coming soon. Thanks.

Change https://go.dev/cl/496957 mentions this issue: cmd/go: allow using go env with unknown vars already in go/env file