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.

Sign up for GitHub

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

Jump to bottom

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

Closed
bradfitz opened this issue Aug 13, 2018 · 4 comments
Closed

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

bradfitz opened this issue Aug 13, 2018 · 4 comments
Labels
FrozenDueToAge modules

Comments

@bradfitz
Copy link
Contributor

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
Copy link
Contributor Author

/cc @bcmills @rsc

@kardianos
Copy link
Contributor

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.

@FiloSottile FiloSottile mentioned this issue Aug 14, 2018
Closed
@rsc
Copy link
Contributor

rsc commented Aug 18, 2018

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

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

@rsc rsc closed this as completed Aug 18, 2018
@rsc
Copy link
Contributor

rsc commented Aug 18, 2018

The tidy with excluded build tags is now #25873.

@cpu cpu mentioned this issue Oct 31, 2018
Merged
@golang golang locked and limited conversation to collaborators Aug 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@bradfitz @rsc @kardianos @gopherbot