Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: 'go list' should not resolve or record modules that are not relevant to the requested output fields #29869

rogpeppe opened this issue Jan 22, 2019 · 6 comments


Copy link

@rogpeppe rogpeppe commented Jan 22, 2019

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

$ go version
go version devel +4b3f04c63b Thu Jan 10 18:15:48 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?


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

go env Output
$ go env
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build480679307=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Here is a script that illustrates the issue (reproduce by saving contents to a file and running the testscript command on it (go get

# Create the module and tidy it.
go mod init m
go mod tidy
cmp go.mod go.mod-after-tidy

# Run a `go list` command to list the parent of the used package.
go list
cmp go.mod go.mod-after-list

# Running `go mod tidy` removes the new dependencies.
go mod tidy
cmp go.mod go.mod-after-tidy

-- main.go --
package main

import _ ""

func main() {
-- go.mod-after-tidy --
module m

go 1.12

require v0.0.0-20180706230648-ab6388e0c60a
-- go.mod-after-list --
module m

go 1.12

require ( v0.0.0-20190115013929-ed77733ec07d // indirect v0.0.0-20180706230648-ab6388e0c60a v0.0.0-20181203042331-505ab145d0a9 // indirect

I would not expect go list to add dependencies that aren't actually used by the code to go.mod.

Copy link

@jayconrod jayconrod commented Jan 22, 2019

Related #29452. I think we need to make a decision on what side effects go list should have before changing.

I believe this is currently working as designed. cmd/go saves information to go.mod so that commands are reproducible (including go list). This is not what many people expect of go list though.

@jayconrod jayconrod added this to the Go1.13 milestone Jan 22, 2019
Copy link

@mvdan mvdan commented Jan 22, 2019

@jayconrod is it the same issue, though? Note that @rogpeppe had the module in question already as a requirement, since go mod tidy was run. In fact, re-running tidy is removing the extra indirect lines once again. I don't think this is simply a "list should have no side effects" issue.

Copy link

@jayconrod jayconrod commented Jan 22, 2019

@mvdan I think it's the same issue. The main module depends on the package, which has no dependencies outside the standard library. go list adds the transitive dependencies of that package. go mod tidy removes those dependencies, since nothing in the main module transitively depends on them.

go mod tidy effectively acts like a garbage collector: it removes requirements on modules which are unreachable from packages in the main module.

Copy link

@bcmills bcmills commented Jan 22, 2019

#29452 is related but distinct.

#26977 is probably the same underlying problem. Arguably both go mod why and go list (without -versions) should avoid resolving the requested package unless it is already in some module in the build list.

Copy link

@bcmills bcmills commented Jan 22, 2019

Hmm, this isn't quite the same as #26977 either: in this case, the package in question is already in an active module, but that module's dependencies have not been resolved.

go list resolves those dependencies as a side-effect of loading the package, but since you didn't actually request any information about the package's imports, we arguably don't need to load them. (See also #29666.)

Copy link

@bcmills bcmills commented Jan 22, 2019

On further consideration, I think this is more-or-less a duplicate of #29666.

In contrast, if you had asked for any substantial information about the dependencies of (for example, by examining the ImportMap field using -f '{{.ImportMap}}' or -json), then the go tool should arguably add the corresponding version information to the go.mod file to ensure that the output of the command is reproducible.

@bcmills bcmills changed the title cmd/go: go list can add dependencies cmd/go: 'go list' should not resolve or record modules that are not relevant to the requested output fields Jan 22, 2019
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.