cmd/go: go mod mvs: explain MVS selection

[jeanbza]

Actually, I'm not sure if it should be go mod mvs, some different subcommand, or rolled into something like go mod why. But, what I'd like is something like:

$ go mod graph
cloud.google.com/go [email protected]
cloud.google.com/go github.com/foo/[email protected]
cloud.google.com/go google.golang.org/[email protected]
google.golang.org/[email protected] [email protected]
github.com/foo/bar [email protected]
$ go mod mvs
[email protected]
    [email protected]
    [email protected]
    [email protected]
github.com/foo/[email protected]
    github.com/foo/[email protected]
google.golang.org/[email protected]
    google.golang.org/[email protected]

I'm also not sure what the exact output should be. The above's output isn't great because it's not easily combined with things like go mod graph. Basically, I'm reaching for a way to get an explanation of which versions of modules were actually picked, and why they were picked.

[bcmills]

I'm reaching for a way to get an explanation of which versions of modules were actually picked, and why they were picked.

Can you give a little more detail on that? A module graph for a binary can be quite large, especially when multiple versions are taken into account, so in general I think it's more productive to ask about specific targets (and, when possible, specific versions).

Probably that implies that you should ask about a specific point in the module dependency graph, and the go command should tell you something about the parts of the graph that lead to that point.

In #28692 (comment), I suggested go mod whynot as a counterpart to go mod why, but didn't give a specific behavior for it. Thinking about that some more, perhaps the behavior should be to show the subgraph leading from the main module to versions of the given module higher than the queried version.

For example, perhaps something like:

$ go mod whynot [email protected]
cloud.google.com/go           [email protected]
cloud.google.com/go           google.golang.org/[email protected]
google.golang.org/[email protected]  [email protected]
google.golang.org/[email protected]  cloud.google.com/[email protected]
cloud.google.com/[email protected]   [email protected]
cloud.google.com/[email protected]   google.golang.org/[email protected]
google.golang.org/[email protected]  [email protected]

[bcmills]

CC @jayconrod @thepudds

[jeanbza]

Can you give a little more detail on that? A module graph for a binary can be quite large, especially when multiple versions are taken into account, so in general I think it's more productive to ask about specific targets (and, when possible, specific versions).

How about,

$ go mod mvs
[email protected]
    [email protected]
    [email protected]
    [email protected]
github.com/foo/[email protected]
    github.com/foo/[email protected]
google.golang.org/[email protected]
    google.golang.org/[email protected]
$ go mod mvs go.opencensus.io
[email protected]
    [email protected]
    [email protected]
    [email protected]

FWIW, I like the whynot idea too.