Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

jayconrod opened this issue May 14, 2019 · 6 comments


Copy link

@jayconrod jayconrod commented May 14, 2019

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.


This comment has been minimized.

Copy link

@bcmills bcmills commented May 14, 2019

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.


This comment has been minimized.

Copy link

@rsc rsc commented May 16, 2019

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


This comment has been minimized.

Copy link

@thepudds thepudds commented May 17, 2019

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 jayconrod modified the milestones: Go1.14, Go1.13 May 17, 2019

This comment has been minimized.

Copy link
Contributor Author

@jayconrod jayconrod commented May 17, 2019

@thepudds Good catch. Now planned for 1.13.


This comment has been minimized.

Copy link

@gopherbot gopherbot commented May 17, 2019

Change mentions this issue: cmd/go: remove support for the 'go get -m' flag

@gopherbot gopherbot closed this in 545cd82 May 30, 2019

This comment has been minimized.

Copy link

@gopherbot gopherbot commented May 31, 2019

Change mentions this issue: cmd/go: recommend -d when -m is used

gopherbot pushed a commit that referenced this issue Jun 7, 2019
In #32038, it was decided to remove get's -m, since one former use case
is removed, and the other can be done via -d, as pointed by Russ.

However, a user getting this short error might not realise that they can
switch to -d to skip building packages. Add a short mention to point
them in the right direction.

It's important to note "packages", because -m was a flag that acted on
modules, while -d acts on packages. Simply replacing -m with -d might
not be enough in some cases because of that distinction.

Change-Id: I0947b25c4223bdad3cd0e535848527da8db8a16d
Reviewed-by: Jay Conrod <>
Reviewed-by: Bryan C. Mills <>
Run-TryBot: Daniel Martí <>
TryBot-Result: Gobot Gobot <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.