cmd/go: "go work use" doesn't clearly indicate when download fails

[lpar]

What version of Go are you using (go version)?

1.20.3

Does this issue reproduce with the latest release?

Can't tell yet

What operating system and processor architecture are you using (go env)?

darwin/arm64

What did you do?

I hit an error because go.mod had been updated to require v1.20.4, but go.work hadn't:

go: module . listed in go.work file requires go >= 1.21.4, but go.work lists go 1.21.3; to update it:
	go work use

So I tried that:

> go work use
go: go.mod requires go >= 1.21.4; switching to go1.21.4
go: downloading go1.21.4 (darwin/arm64)
go: download go1.21.4: golang.org/toolchain@v0.0.1-go1.21.4.darwin-arm64: verifying module: checksum database disabled by GOSUMDB=off

My first issue is that I understood "go.work lists go 1.21.3; to update it: go work use" to mean that go work use would update go.work, and I'd then switch Go versions in the usual way (for me, using rtx). I didn't think "update it" meant "download and use go 1.21.4". So that message could use clarification.

My second issue is that Go seemed to have downloaded a different version of Go and presumably stored it somewhere. I didn't want an extra copy of Go 1.21.4 hanging around, so I set about trying to find it. After wasting quite a lot of time on that, I ran across this text in https://go.dev/doc/toolchain:

Instead, toolchain downloads fail for lack of verification if GOSUMDB=off.

So I think the second message, from go work use, could also use clarification. Specifically, if the download fails, it should clearly state that the download failed, rather than merely saying that the checksum database is disabled (which I know) and leaving the reader to work out what might have happened.

It'd also be good if Go checked to see if go work use was going to work (i.e. if GOSUMDB was enabled) before suggesting that the user run it.

(I also think it would be a good idea to have a better way to disable this auto-download-and-run functionality than having to turn off GOSUMDB. I don't want to keep an old version of Go around and have it download multiple newer versions as necessary. Rather, I want to continue to use a tool like rtx to manage my default Go install, so that when I run go to build a project I get the current version by default, even if that project doesn't require it.)

[heschi]

cc @bcmills @matloob

[bcmills]

I also think it would be a good idea to have a better way to disable this auto-download-and-run functionality than having to turn off GOSUMDB.

There is: see https://go.dev/doc/toolchain#GOTOOLCHAIN.
It seems like what you're looking for is probably either GOTOOLCHAIN=local or GOTOOLCHAIN=path?

[bcmills]

I agree that the verifying module: checksum database disabled error message ought to be clearer about whether the module was actually downloaded before verification failed, and should certainly check the availability of the checksum before starting the download. That part is concrete and actionable; please file it as a separate issue.

[bcmills]

I don't think it would be worth the implementation complexity to determine whether go work use will succeed before suggesting it in the error text. It is unambiguously the right command to run to fix that particular problem, and if it fails, the next step for the user is to determine why it failed and correct that problem.

In your case, the way to correct the problem is to upgrade to a go version that is able to complete the command itself without switching toolchains.

[bcmills]

@lpar, this issue combine multiple complaints about several different parts of the workflow; it does not seem actionable as a self-contained issue. It's also not clear to me which problems are problems of documentation vs. error-message clarity vs. objections to the underlying features.

Please do feel free to suggest concrete changes to the error text and/or documentation — it can be difficult to balance clarity and precision, especially as someone who is already familiar with the implementation and semantics. However, it's not so helpful to just say that they ought to be clearer — we have tried to make them clear to begin with.

[lpar]

Suggested message rephrasing:

go: module . listed in go.work file requires go >= 1.21.4, but go.work lists go 1.21.3; to download and use go 1.21.4:
	go work use

> go work use
go: go.mod requires go >= 1.21.4; switching to go1.21.4
go: downloading go1.21.4 (darwin/arm64)
go: download go1.21.4: golang.org/toolchain@v0.0.1-go1.21.4.darwin-arm64: download failed: checksum database disabled by GOSUMDB=off

[raghvenders]

@bcmills , @lpar - I am rewriting above reprhasing as it still suggests go work use. But my understanding is to download and update the PATH go. Correct me if better verbose needed. I am sending CL for this.

go: module . listed in go.work file requires go >= 1.21.4 as these modules <mod1,mod2> uses 1.21.4, but go.work lists go 1.21.3; Upgrate to go 1.21.4 ( Download and install) and update the PATH accordingly.

[raghvenders]

@bcmills - Kindly update the Label to Needs Fix(my CL is on way) as I have finished my investigation. How can I add , update or remove labels myself?

@lpar - Your go version says "1.20.3" but your switching is from 1.21.3 => 1.21.4.
Are you sure?

I am able to reproduce the issue. That is possible by keeping GOSUMDB=off rather then GOSUMDB=sum.golang.org. However with correct GOSUMDB, this works as expected and switching of toolchain is happening.

So wouldn't the message be

go: module . listed in go.work file requires go >= 1.21.4, but go.work lists go 1.21.3; Check if GOSUMDB is not off and do update it:
go work use

[raghvenders]

Please review : https://go-review.googlesource.com/c/go/+/542696

[gopherbot]

Change https://go.dev/cl/542696 mentions this issue: cmd/go: Fix for #64007 - For Too old go workspace against local go or go module - verbose modified to use go work use or upgrading the installed golang version