minor tweaks to recent material

thepudds 2018-12-07 12:53:41 -05:00
parent 584c4bb6fd
commit bfa9eca33c

@ -878,7 +878,7 @@ Please see the question "Won't minimal version selection keep developers from ge
2. The second step usually should be to check `go list -m all` to see the list of actual versions selected for your build. `go list -m all` shows you the final selected versions, including for indirect dependencies and after resolving versions for any shared dependencies. It also shows the outcome of any `replace` and `exclude` directives.
3. A good next step can be to examine the output of `go mod graph` or `go mod graph | grep <module-of-interest>`. `go mod graph` prints the module requirement graph (including taking into account replacements). Each line in the output has two fields: the first column is a consuming module, and the second column is one of that module's requirements (including the version required by that consuming module). This can be a quick way to see which modules are requiring a particular dependency, including when you different versions required for shared dependencies.
3. A good next step can be to examine the output of `go mod graph` or `go mod graph | grep <module-of-interest>`. `go mod graph` prints the module requirement graph (including taking into account replacements). Each line in the output has two fields: the first column is a consuming module, and the second column is one of that module's requirements (including the version required by that consuming module). This can be a quick way to see which modules are requiring a particular dependency, including when your build has different version numbers required for shared dependencies.
`go mod why -m <module>` can also be useful here, although it is typically more useful for seeing why a dependency is included at all (rather than why a dependency ends up with a particular version).