CC @matloob @bcmills

I expect to see a similar error message whether [GO111MODULE] is specified or not. The setting of that environment variable seems irrelevant for whether the Go package exists.

As of Go 1.22, “go get is no longer supported outside of a module”. So the setting of the environment variable matters a lot: if it is set to off, go get doesn't work at all (and thus cannot report an error relating to a specific package).

So the difference in errors here is correct, but perhaps in the GO111MODULE=off case we could add a note specific to go get.

Thanks. I now think that the general error should be improved to say something like go get requires module mode, which has been disabled by GO111MODULES=off. Since go get used to work in non-module mode, the error message isn't clear about what the problem is.

(@samthanawalla, want to take a look at this one?)

Do you mind if I fix this problem?

The new output is similar to the image below.

Change https://go.dev/cl/574595 mentions this issue: cmd/go/internal/modload: go get provides clearer errors when GO111MODULE=off

I think to enable these more refined error messages, we need to work towards #40775
More specifically, modifying modload.Init to return errors instead of using base.Fatal in every case.

I think to enable these more refined error messages, we need to work towards #40775 More specifically, modifying modload.Init to return errors instead of using base.Fatal in every case.

Thank you for your reply. I will try to research the ##40775

@cuishuang We're thinking about how best to address this. Please hold off on making further changes for now.

@cuishuang We're thinking about how best to address this. Please hold off on making further changes for now.

Ok. Thanks