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: "mod why" should show all the paths to a package or module #41305

Open
mvdan opened this issue Sep 9, 2020 · 5 comments
Open

cmd/go: "mod why" should show all the paths to a package or module #41305

mvdan opened this issue Sep 9, 2020 · 5 comments

Comments

@mvdan
Copy link
Member

@mvdan mvdan commented Sep 9, 2020

It would be nicer if go mod why gave all the paths to a package or module, not just the shortest path. This would help answer common questions like "what would it take to remove dependency X?".

I can get that information indirectly via go list -deps -json or go mod graph, processing or plotting the output somehow. Or even using third party tools like https://github.com/loov/goda.

Still, I think this rather simple change would make go mod why significantly more useful for simple use cases, without having to go to something much more involved like a graph or a dependency query language.

@mvdan
Copy link
Member Author

@mvdan mvdan commented Sep 9, 2020

Having said this, I think some sort of query language is also very useful, but both features can and should coexist. And it seems fine for the query language to exist in a third party tool.

@bcmills
Copy link
Member

@bcmills bcmills commented Sep 10, 2020

The syntax for this is a bit tricky. With a single path, the output can just be the nodes (packages) along the path. With the complete import subgraph, we would presumably need some way to show the edges too.

But I guess go mod graph does already have a format for edges...

@mvdan
Copy link
Member Author

@mvdan mvdan commented Sep 10, 2020

What I was initially thinking would be to expand the newline-separated output with the possibility for many empty-line-separated groups:

$ go mod why baz
foo
bar
baz

foo
some-other-bar
baz

Another option could be to piggyback off of the go mod graph edge format, so that we would just show the sub-graph for all paths that reach the destination:

$ go mod why baz
foo bar
bar baz
foo some-other-bar
some-other-bar baz

I personally prefer the first, because I find it easier to understand for a human.

@bcmills
Copy link
Member

@bcmills bcmills commented Sep 10, 2020

I don't think groups are viable in general: even neglecting cycles (which are possible with build constraints), the number of unique paths is exponential with the number of nodes in the worst case.

@mvdan
Copy link
Member Author

@mvdan mvdan commented Sep 10, 2020

Then perhaps the answer is to provide a go mod graph that spits the output for the package import graph, not the module dependency graph. Then one can visualize, query, or inspect that as needed.

One can get that information via go list -deps -json all, but it requires more work. And any tools which currently understand the go mod graph output could easily work out of the box.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

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