cmd/go: `go get` should give a clearer error with `GO111MODULE=off`

[ianlancetaylor]

Go version

6f5d774

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/iant/.cache/go-build'
GOENV='/home/iant/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/iant/gopath/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/iant/gopath'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org'
GOROOT='/home/iant/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/iant/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.23-6f5d77454e Sat Mar 2 14:01:52 2024 +0000'
GODEBUG=''
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/iant/go/src/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3030176309=/tmp/go-build -gno-record-gcc-switches'

What did you do?

> GO111MODULE=off go get -v go.wit.com/apps/test
go: modules disabled by GO111MODULE=off; see 'go help modules'
> go get -v go.wit.com/apps/test
go: module go.wit.com/apps/test: reading https://proxy.golang.org/go.wit.com/apps/test/@v/list: 404 Not Found
	server response: not found: go.wit.com/apps/test@latest: unrecognized import path "go.wit.com/apps/test": parse https://go.wit.com/apps/test?go-get=1: no go-import meta tags ()

What did you see happen?

See above.

What did you expect to see?

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

[mknyszek]

CC @matloob @bcmills

[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.

[ianlancetaylor]

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.

[bcmills]

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

[cuishuang]

Do you mind if I fix this problem?

The new output is similar to the image below.

[gopherbot]

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

[samthanawalla]

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.

[cuishuang]

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