go list with modules will find the versions to all modules when only asked for a subset

[jsternberg]

What did you do?

This is easiest to produce if you use docker because it's an issue when the go mod cache is empty.

1. Download any project that uses go modules. For this example, I'm using gomods/athens since I was playing with the registry.

$ git clone git://github.com/gomods/athens

2. Run inside of a docker container with modules enabled and with the volume shared.

$ docker run --rm -it -v $PWD:/go/src/github.com/gomods/athens -w /go/src/github.com/gomods/athens -e GO111MODULE=on golang:1.11

3. Run any of the list commands on the main module or a specific module and do not ask for any dependencies. I am using -json below, but this also happens without -json.

$ go list -m -json

What did you expect to see?

{
        "Path": "github.com/gomods/athens",
        "Main": true,
        "Dir": "/go/src/github.com/gomods/athens",
        "GoMod": "/go/src/github.com/gomods/athens/go.mod"
}

I did not expect it to evaluate each one of the versions for each module when it wasn't asked for them.

What did you see instead?

It ran the find algorithm on every single dependency in go.mod so you see a stream of things like this:

go: finding github.com/nicksnyder/go-i18n v1.10.0
go: finding github.com/shurcooL/highlight_diff v0.0.0-20170515013008-09bb4053de1b
go: finding github.com/gobuffalo/makr v1.1.1
go: finding golang.org/x/net v0.0.0-20180808004115-f9ce57c11b24
go: finding github.com/dustin/go-humanize v0.0.0-20180713052910-9f541cc9db5d
go: finding github.com/gobuffalo/uuid v2.0.0+incompatible
go: finding github.com/shurcooL/sanitized_anchor_name v0.0.0-20170918181015-86672fcb3f95
go: finding github.com/sourcegraph/annotate v0.0.0-20160123013949-f4cad6c6324d
go: finding github.com/go-playground/universal-translator v0.16.0
go: finding github.com/davecgh/go-spew v1.1.0

If you are just trying to read the current module path, this slows things down a bunch when you have a new repository because it is attempting to find all of the possible versions for modules that it already has a version for.

It then finally prints the module path. But I only asked for the main module path. The -json output doesn't appear to use any information that it would retrieve from the above modules and go.mod already has the list of versions that it's going to use because there are no references to branches and there are no update operations to change the file. The go list command is also not being asked for it to evaluate imports.

System details

go version go1.11 darwin/amd64
GOARCH="amd64"
GOBIN="/Users/jsternberg/go/pkg/bin/github.com/gomods/athens"
GOCACHE="/Users/jsternberg/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/jsternberg/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/jsternberg/go/src/github.com/gomods/athens/go.mod"
GOROOT/bin/go version: go version go1.11 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.11
uname -v: Darwin Kernel Version 17.7.0: Fri Jul  6 19:54:51 PDT 2018; root:xnu-4570.71.3~2/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.13.6
BuildVersion:	17G2307
lldb --version: lldb-1000.11.37.1
  Swift-4.2

[myitcv]

cc @rsc @bcmills

[bcmills]

Duplicate of #27479.

[jsternberg]

I think #27479 is a bit different, although they are certainly related. This issue has to do with the behavior of how modules are treated, module queries, and how the module versions are resolved when they are loaded from go.mod. That other issue has to do with listing packages. As an example, this comment makes a lot more sense when you are talking about listing packages, but I'm not sure it makes sense when you are just trying to list the version of a module that's already specified in the go.mod file since that issue doesn't have anything to do with how modules are resolved from go.mod.