cmd/go: should `go list -versions` list cached versions when GOPROXY=off?

[bcmills]

Users can set GOPROXY=off to disable module fetches. When that is set, however, they can still resolve versions that are already present in the local cache.

However, it can be difficult to figure out what those versions actually are: go list -versions -m $MODULE produces unhelpful error output (#32335) if the module is not present in the proxy, and truncated output if the module is present:

example.com$ gotip version
go version devel +220552f6 Thu May 30 17:59:57 2019 +0000 linux/amd64

example.com$ gotip mod init example.com
go: creating new go.mod: module example.com

example.com$ GOPROXY='' gotip list -versions -m rsc.io/quote
go: finding rsc.io/quote v1.5.2
rsc.io/quote v1.0.0 v1.1.0 v1.2.0 v1.2.1 v1.3.0 v1.4.0 v1.5.0 v1.5.1 v1.5.2 v1.5.3-pre1

example.com$ GOPROXY=off gotip list -versions -m rsc.io/quote
go list -m rsc.io/quote: module "rsc.io/quote" is not a known dependency

example.com$ GOPROXY='' gotip get rsc.io/quote@latest
go: finding rsc.io/sampler v1.3.0
go: finding golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
go: downloading rsc.io/quote v1.5.2
go: extracting rsc.io/quote v1.5.2
go: downloading rsc.io/sampler v1.3.0
go: extracting rsc.io/sampler v1.3.0
go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
go: extracting golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c

example.com$ GOPROXY=off gotip list -versions -m rsc.io/quote
rsc.io/quote

example.com$

---

The workaround is to set GOPROXY="file://$GOPATH/pkg/mod/cache/download" before running go list:

example.com$ GOPROXY="file://$GOPATH/pkg/mod/cache/download" gotip list -versions -m rsc.io/quote
rsc.io/quote v1.5.2

example.com$

Unfortunately, that's really not discoverable (Paul's example notwithstanding).

---

Instead, I propose that when GOPROXY is set to off, go list -versions should list the versions that are available without consulting the proxy, as if the user had set GOPROXY="file://$GOPATH/pkg/mod/cache/download".

I don't see any other reasonable behavior we could provide in that case, and that would turn an otherwise useless-in-context command into a useful one.

CC @jayconrod @hyangah @thepudds @myitcv @rsc

[myitcv]

I'm more than likely behind in the conversation, but to me GOPROXY=off simply says "don't use the proxy". Which could/should mean "go direct", rather than "go local"?

[hyangah]

Thanks @bcmills for filing this issue.

A bit more context behind this feature request: I found using Go without network access became harder and requires more learning in module mode than in the old GOPATH mode. In module mode, the best I could do was to ensure they are in the module cache or somewhere Go can recognize as a file proxy, but that is still insufficient because many Go commands will not work unless I explicitly set GOPROXY=file://$GOPATH/pkg/mod/cache/download (which I will never memorize) or the go.mod files in my workspace already specify the module and its version completely.

Another option I thought about is to have another GOPROXY mode (maybe GOPROXY=local, an alias of GOPROXY=file://$GOPATH/pkg/mod/cache/download). Unlike GOPROXY=off, I hope this mode to allow go get to pick up the latest module/version available in the module cache even when the module, version is not specified in go.mod yet. But given that GOPROXY=off is already confusing as @myitcv pointed out, I am not sure introducing another mode is a good idea.

No matter what decision Go team makes on this specific issue, I hope improvement in user experience when using Go without network.