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: do not resolve missing imports in 'go mod why' #26977

FiloSottile opened this issue Aug 14, 2018 · 3 comments


Copy link

@FiloSottile FiloSottile commented Aug 14, 2018

Starting at

$ GO111MODULE=on go1.11rc1 mod init
go: creating new go.mod: module
go: copying requirements from Gopkg.lock

$ GO111MODULE=on go1.11rc1 mod vendor
go: finding v0.0.0-20180609054337-500bd5b9081b
go: finding v0.0.0-20180114231543-2291e8f0f237
go: finding v0.0.0-20180627171509-e514e69ffb8b
go: finding v0.3.0
go: downloading v0.0.0-20180114231543-2291e8f0f237
go: downloading v0.0.0-20180627171509-e514e69ffb8b
go: downloading v0.0.0-20180609054337-500bd5b9081b
go: downloading v0.3.0

$ cat go.mod

require ( v0.0.0-20180609054337-500bd5b9081b v0.0.0-20180627171509-e514e69ffb8b v0.3.0 // indirect v0.0.0-20180114231543-2291e8f0f237

So far so good. It builds, and everything works.

Then I run go mod why (which does not answer me because I want #26968).

$ GO111MODULE=on go1.11rc1 mod why
go: finding latest
go: downloading v0.0.0-20180609054337-500bd5b9081b
(main module does not need package

And now a new line appeared in the go.mod, which does not seem something I should expect?

diff --git a/go.mod b/go.mod
index 458640f..cd3792e 100644
--- a/go.mod
+++ b/go.mod
@@ -4,5 +4,6 @@ require ( v0.0.0-20180609054337-500bd5b9081b v0.0.0-20180627171509-e514e69ffb8b v0.3.0 // indirect
+ v0.0.0-20180609054337-500bd5b9081b // indirect v0.0.0-20180114231543-2291e8f0f237
diff --git a/go.sum b/go.sum
index 68659a5..1f591aa 100644
--- a/go.sum
+++ b/go.sum
@@ -4,5 +4,7 @@ v0.0.0-20180627171509-e514e69ffb8b h1:oXs/nlnyk1ue6g+mFGEHIuIaQ v0.0.0-20180627171509-e514e69ffb8b/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= v0.3.0 h1:g61tztE5qeGQ89tm6NTjjM9VPIm088od1l6aSorWRWg= v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= v0.0.0-20180609054337-500bd5b9081b h1:r4LwkXZhdblHVSgAvfRjsFpQBorl6S9pAH+AOHVs+28= v0.0.0-20180609054337-500bd5b9081b/go.mod h1:jInWmjR7JRkkon4jlLXDZGVEeY/wo3kOOJEWYhNE+9Y= v0.0.0-20180114231543-2291e8f0f237 h1:iAEkCBPbRaflBgZ7o9gjVUuWuvWeV4sytFWg9o+Pj2k= v0.0.0-20180114231543-2291e8f0f237/go.mod h1:/xvNRWUqm0+/ZMiF4EX00vrSCMsE4/NHb+Pt3freEeQ=

This comment has been minimized.

Copy link

@rsc rsc commented Aug 17, 2018

Maybe we can revisit in Go 1.12.

@rsc rsc modified the milestones: Go1.11, Go1.12 Aug 17, 2018

This comment has been minimized.

Copy link

@dmitris dmitris commented Oct 8, 2018

seeing the same issue (with fo1.11.1), go mod why <pkg> functions as go mod tidy - even though there seems to be nothing in the go mod help tidy regarding that, and as a user I don't expect a "why" query to have silent side-effect modifications on go.mod


This comment has been minimized.

Copy link

@bcmills bcmills commented Sep 23, 2019

I think the fix here is to make go mod why simply skip over imports that are not satisfied by any existing module dependency.

That would also address the problem in #34432, in which an error in an unresolved dependency prevents go mod why from producing useful output for an unrelated module.

CC @jayconrod

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
5 participants
You can’t perform that action at this time.