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: clarify which dependencies are updated by 'get -u' without '-m' #26902

bcmills opened this Issue Aug 9, 2018 · 4 comments


None yet
3 participants

bcmills commented Aug 9, 2018

At the moment go get -u -d . in module mode updates all dependencies of the main module, and as of, go get -u -d $PKG for any package in the main module will do the same.

The current documentation is ambiguous on this point. It says:

The -u flag instructs get to update dependencies to use newer minor or patch releases when available. Continuing the previous example, 'go get -u A' will use the latest A with B v1.3.1 (not B v1.2.3).


When using -m, each specified package path must be a module path as well, not the import path of a package below the module root.


With no package arguments, 'go get' applies to the main module, and to the Go package in the current directory, if any. In particular, 'go get -u' and 'go get -u=patch' update all the dependencies of the main module.

The documentation is ambiguous because it does not clarify which “dependencies” go get updates

  • “package dependencies”, the set of modules containing the transitive closure of imports of a package, or
  • “module dependencies” the set of modules that are required by the module containing the package, or
  • something else, such as the union of the package and module dependencies.

My intuition is that, without the -m flag, get -u should update the package dependencies: the user is requesting a specific package, not (necessarily) a module, and because go.mod files are currently very sparse, any given package may have a large number of package dependencies that are not module dependencies. We should not fail to update those dependencies, so we should not upgrade only “module dependencies”. On the other hand, “the union of package and module dependencies” seems more complicated to explain.

If I understand @rsc correctly, (in, he has some other alternative in mind, although I'm not sure which.

@bcmills bcmills added this to the Go1.11 milestone Aug 9, 2018

@bcmills bcmills added modules woh and removed woh labels Aug 9, 2018


This comment has been minimized.

timtadh commented Aug 14, 2018

As a 👍 I am currently very confused as to how to properly do updates to dependencies. For instance, let's say I specify package a <v1.2 and have some other packages: b, c, and d whose versions I don't care about. I want to be able to run go get -u (or something similar) and have it update just a,b,c, and d while respecting my constraint a <v1.2 such that if I was at a v1.1.1 it could now be a v1.1.2 but not a v1.2.3. Can't figure out how to do this now.


This comment has been minimized.


rsc commented Aug 17, 2018

We'll look more carefully at this in Go 1.12.

@rsc rsc modified the milestones: Go1.11, Go1.12 Aug 17, 2018


This comment has been minimized.

timtadh commented Aug 17, 2018



This comment has been minimized.


bcmills commented Nov 13, 2018

A similar ambiguity exists for go mod download without an explicit argument: should it download source code for all modules in the module graph, or only those required to be able to go test all in all build configurations? (I would argue that the latter is more user-friendly, since the general use case for go mod download is to run some subset of go test all.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment