cmd/go: should 'go get -m -u' only consider dependencies of the main module?

[jayconrod]

Since CL 174099, go get -m -u A upgrades module A to the latest version, as well as modules providing packages transitively imported by packages in A. This may introduce requirements on modules not needed to build packages in the main module, i.e., requirements that would be removed by go mod tidy.

For example, suppose that:

• Module A has packages A/x and A/y.
• A/y imports B/z in module B.
• Packages in the main module import A/x, but not A/y or anything else that transitively imports B.

go get -m -u A will upgrade both A and B to the latest version, probably introducing a requirement on B in go.mod.

@bcmills suggested that we tweak the meaning of go get -m -u A a little bit. The -m flag causes us to expand A to the set of packages provided by module A. For the purpose of -u, we could intersect that set with all, giving us the set of packages provided by module A needed to build packages in the main module.

With this change, go get -m -u A in the example above would update A but not B, since the argument A would expand to the package A/x but not A/y.

@rsc Any thoughts? @bcmills and I discussed this for a while this morning, but we didn't reach a conclusion. It seems like a useful change, but it adds some complexity.

[bcmills]

I discussed this with @rsc earlier today.
To summarize his commentary:

• In Go 1.12, since module-mode go get didn't consider the package graph at all, -m meant “stop after computing the new module graph, before loading packages” — it didn't actually change the semantics of the earlier steps.
• Now, without -m, the upgrade phase of go get loads packages before it even computes the module graph, so there is no logical stopping point in between the two.
• The -d flag did, and still does, mean “stop after downloading source code”.

Since the -m stopping point between computing the graph and loading packages no longer exists, @rsc suggested that we simply remove the -m flag.

[rsc]

Yes, let's remove -m. Any uses that want to avoid the build should now use -d (like pre-modules).

[thepudds]

Milestone here was set to 1.14, but then a day or so later release-blocker was added. Just wanted to double-check if 1.14 milestone is still intended here.

[jayconrod]

@thepudds Good catch. Now planned for 1.13.

[gopherbot]

Change https://golang.org/cl/177879 mentions this issue: cmd/go: remove support for the 'go get -m' flag