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 go.opencensus.io@v0.21.0
cloud.google.com/go github.com/foo/bar@v0.0.1
cloud.google.com/go google.golang.org/api@v0.4.0
google.golang.org/api@v0.4.0 go.opencensus.io@v0.22.0
github.com/foo/bar go.opencensus.io@v0.17.3
$ go mod mvs
go.opencensus.io@v0.22.0
    go.opencensus.io@v0.22.0
    go.opencensus.io@v0.21.0
    go.opencensus.io@v0.17.3
github.com/foo/bar@v0.0.1
    github.com/foo/bar@v0.0.1
google.golang.org/api@v0.4.0
    google.golang.org/api@v0.4.0

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 go.opencensus.io@v0.17.3
cloud.google.com/go           go.opencensus.io@v0.22.0
cloud.google.com/go           google.golang.org/api@v0.7.0
google.golang.org/api@v0.7.0  go.opencensus.io@v0.21.0
google.golang.org/api@v0.7.0  cloud.google.com/go@v0.38.0
cloud.google.com/go@v0.38.0   go.opencensus.io@v0.21.0
cloud.google.com/go@v0.38.0   google.golang.org/api@v0.4.0
google.golang.org/api@v0.4.0  go.opencensus.io@v0.21.0

[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
go.opencensus.io@v0.22.0
    go.opencensus.io@v0.22.0
    go.opencensus.io@v0.21.0
    go.opencensus.io@v0.17.3
github.com/foo/bar@v0.0.1
    github.com/foo/bar@v0.0.1
google.golang.org/api@v0.4.0
    google.golang.org/api@v0.4.0
$ go mod mvs go.opencensus.io
go.opencensus.io@v0.22.0
    go.opencensus.io@v0.22.0
    go.opencensus.io@v0.21.0
    go.opencensus.io@v0.17.3

FWIW, I like the whynot idea too.

[jeanbza]

This is probably stale.