cmd/go: support "go mod why <module>", support tidy with excluded build tags?

[bradfitz]

I was just looking in a go.mod file of mine and saw google.golang.org/appengine:

$ cat go.mod
module github.com/bradfitz/private/mon

require (
        github.com/bradfitz/powerview v0.0.0-20160116203152-8294e076c826
        github.com/edmore/goca v0.0.0-20131206114006-0c390598dd87
        github.com/golang/protobuf v1.1.0 // indirect
        github.com/google/tcpproxy v0.0.0-20180808230851-dfa16c61dad2
        golang.org/x/crypto v0.0.0-20180808211826-de0752318171
        golang.org/x/net v0.0.0-20180811021610-c39426892332
        golang.org/x/oauth2 v0.0.0-20180724155351-3d292e4d0cdc
        golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f // indirect
        google.golang.org/appengine v1.1.0 // indirect
)

I found that really odd, as my code doesn't run on the cloud and uses nothing related to App Engine.

So I ran mod tidy hoping it'd go away (but it didn't) and then go mod why:

$ GO111MODULE=on go mod tidy
$ GO111MODULE=on go mod why google.golang.org/appengine
# google.golang.org/appengine
(main module does not need package google.golang.org/appengine)

Umm. More mysteries.

Turns out go mod why only accepts packages, not modules.

But I only have modules to ask about.

The way I figured this out was nuking my go.mod file and re-running tidy to see a package in the module:

dev:mon $ GO111MODULE=on go mod init
go: creating new go.mod: module github.com/bradfitz/private/mon
dev:mon $ GO111MODULE=on go mod tidy
go: finding github.com/edmore/goca/auth latest
go: finding github.com/google/tcpproxy latest
go: finding github.com/edmore/goca latest
go: finding github.com/bradfitz/powerview latest
go: finding golang.org/x/net/context latest
go: finding golang.org/x/net latest
go: finding golang.org/x/net/context/ctxhttp latest
go: finding golang.org/x/oauth2 latest
go: finding golang.org/x/crypto/acme/autocert latest
go: finding golang.org/x/crypto/acme latest
go: finding golang.org/x/crypto latest
go: finding google.golang.org/appengine/urlfetch latest
go: finding github.com/golang/protobuf/proto latest
go: finding golang.org/x/sync/errgroup latest
go: finding golang.org/x/sync latest

And then I saw that it was google.golang.org/appengine/urlfetch so I could finally run:

dev:mon $ GO111MODULE=on go mod why google.golang.org/appengine/urlfetch
# google.golang.org/appengine/urlfetch
github.com/bradfitz/private/mon
golang.org/x/oauth2
golang.org/x/oauth2/internal
google.golang.org/appengine/urlfetch

What? Why is oauth2/internal depending on App Engine? Oh, it's not:

https://github.com/golang/oauth2/blob/master/internal/client_appengine.go

That's behind a build tag.

Okay, so go mod tidy is not what I want here.

Delete it all and instead tidy-by-building:

dev:mon $ rm go.mod
dev:mon $ GO111MODULE=on go mod init
go: creating new go.mod: module github.com/bradfitz/private/mon
dev:mon $ GO111MODULE=on go build
go: finding github.com/edmore/goca/auth latest
go: finding github.com/bradfitz/powerview latest
go: finding github.com/edmore/goca latest
go: finding github.com/google/tcpproxy latest
go: finding golang.org/x/crypto/acme/autocert latest
go: finding golang.org/x/oauth2 latest
go: finding golang.org/x/crypto/acme latest
go: finding golang.org/x/crypto latest
go: finding golang.org/x/net/context/ctxhttp latest
go: finding golang.org/x/net/context latest
go: finding golang.org/x/net latest
dev:mon $ cat go.mod
module github.com/bradfitz/private/mon

require (
        github.com/bradfitz/powerview v0.0.0-20160116203152-8294e076c826
        github.com/edmore/goca v0.0.0-20131206114006-0c390598dd87
        github.com/google/tcpproxy v0.0.0-20180808230851-dfa16c61dad2
        golang.org/x/crypto v0.0.0-20180808211826-de0752318171
        golang.org/x/net v0.0.0-20180811021610-c39426892332
        golang.org/x/oauth2 v0.0.0-20180724155351-3d292e4d0cdc
)

Much better.

But two requests:

• I wish go mod why let me ask questions with modules instead of packges
• I wish I could go mod tidy and ignore the "appengine" build tag (or other build tags). Or only tidy with my current build tags, not all.

[bradfitz]

/cc @bcmills @rsc

[kardianos]

There are a number of go mod sub-commands that do analysis on the full dependency graph, as you discovered. This is one reason I filled: #25873 . @rsc Has a reasonable compromise to only put this information in the vendor subcommand per comment #25873 (comment) . But as you noted, it would still leave the other analysis hanging. My original proposal to allow something like exclude tag:appengine would then affect the local modules full graph analysis and thus not try to pull in such dependencies. This would still be my preference.

I agree that go mod why should probably take a module path as well.

[rsc]

Turns out go mod why only accepts packages, not modules.

Use go mod why -m. (It's even documented.)

[rsc]

The tidy with excluded build tags is now #25873.