cmd/go: 'go mod why' should have an answer for every module in 'go list -m all'

[bcmills]

Currently, if you run go mod why -m on the output of every module in go list -m all, some modules may come back with the answer (main module does not need module […]), even after a go mod tidy.

The reason is that the module graph is conservative: go list -m all answers the question “which module versions are implied by the requirements of the main module?”, not “which modules does the main module need to download to complete go list all?”.¹

In contrast, go mod why explicitly ties its answer to go list all.

We should have some flag to go mod why to answer the related go list -m all question, “what path of requirements imposes the version requirement on module x?”

---

¹The command to answer the latter question, as it turns out, is:

go list -f '{{with .Module}}{{.Path}} {{.Version}}{{end}}' all | sort -u

[myitcv]

In contrast, go mod why explicitly ties its answer to go list all.

I don't think this is true, because go list all is subject to build constraints. The statement would be true if we were to say the union of go list all for all possible build constraints, or the hypothetical go list -nobuild all which would enable go list to list package irrespective of build constraints.

Consider github.com/myitcvscratch/depanalysis/cmd/analyzer. The main package whose import path coincides with the module path effectively sits behind a js,wasm build constraint. As does one of its dependencies.

This is therefore unsurprising:

$ go list
can't load package: package github.com/myitcvscratch/depanalysis/cmd/analyzer: build constraints exclude all Go files in /tmp/depanalysis/cmd/analyzer

If we provide the constraints we can list the main package:

$ GOOS=js GOARCH=wasm go list
github.com/myitcvscratch/depanalysis/cmd/analyzer

Similarly, unless we satisfy the constraints, go list all won't work either:

$ go list -f "{{if not .Standard}}{{.ImportPath}}{{end}}" all | sort -u
go: warning: "all" matched no packages

Again, fixed:

$ GOOS=js GOARCH=wasm go list -f "{{if not .Standard}}{{.ImportPath}}{{end}}" all | sort -u
github.com/myitcvscratch/depanalysis/cmd/analyzer
github.com/myitcvscratch/depanalysis/jsdep
github.com/myitcvscratch/depanalysis/normdep

go list -m is not subject to build constraints; it's operating at the module level, and therefore outside the build:

$ go list -m all
github.com/myitcvscratch/depanalysis/cmd/analyzer
github.com/myitcvscratch/depanalysis v0.0.1
github.com/myitcvscratch/depanalysis/distant v0.0.1

Hence it is not equivalent to a go list -f where we output the module path:

$ go list -f "{{if not .Standard}}{{.Module.Path}}{{end}}" all | sort -u
go: warning: "all" matched no packages

Because when listing packages we need to consider build constraints:

$ GOOS=js GOARCH=wasm go list -f "{{if not .Standard}}{{.Module.Path}}{{end}}" all | sort -u
github.com/myitcvscratch/depanalysis
github.com/myitcvscratch/depanalysis/cmd/analyzer

go list -m gives the nodes of the requirement graph output by go mod graph:

$ go mod graph
github.com/myitcvscratch/depanalysis/cmd/analyzer github.com/myitcvscratch/depanalysis@v0.0.1
github.com/myitcvscratch/depanalysis@v0.0.1 github.com/myitcvscratch/depanalysis/distant@v0.0.1

The docs for go mod why say:

By default, why queries the graph of packages matched by "go list all",
which includes tests for reachable packages.

But that does not appear to be the case. go mod why instead seems to correspond to the hypothetical go list -nobuild all mentioned above:

$ go mod why github.com/myitcvscratch/depanalysis/jsdep
# github.com/myitcvscratch/depanalysis/jsdep
github.com/myitcvscratch/depanalysis/cmd/analyzer
github.com/myitcvscratch/depanalysis/jsdep

$ go mod why github.com/myitcvscratch/depanalysis/normdep
# github.com/myitcvscratch/depanalysis/normdep
github.com/myitcvscratch/depanalysis/cmd/analyzer
github.com/myitcvscratch/depanalysis/normdep

$ go mod why github.com/myitcvscratch/depanalysis/unused
# github.com/myitcvscratch/depanalysis/unused
(main module does not need package github.com/myitcvscratch/depanalysis/unused)

$ go mod why image/jpeg
# image/jpeg
github.com/myitcvscratch/depanalysis/cmd/analyzer
fmt
reflect
reflect.test
encoding/json
encoding/json.test
image
image.test
image/jpeg

$ go mod why -m github.com/myitcvscratch/depanalysis
# github.com/myitcvscratch/depanalysis
github.com/myitcvscratch/depanalysis/cmd/analyzer
github.com/myitcvscratch/depanalysis/jsdep

$ go mod why -m github.com/myitcvscratch/depanalysis/distant
# github.com/myitcvscratch/depanalysis/distant
(main module does not need module github.com/myitcvscratch/depanalysis/distant)

As you say, we need the ability to answer the question "why does github.com/myitcvscratch/depanalysis/distant appear in our module requirement graph?"

I'm less clear we need something like a -nobuild flag for go list. Instead, on the (rather dangerous) assumption my analysis correct, I think the docs for go mod why need a slight tweak.

[mwf]

Please, keep in mind the case with test dependencies - would be cool if go mod why could tell if the dependency is used transitively in tests - #30206