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

Open
bcmills opened this Issue Aug 9, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@bcmills
Member

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 https://golang.org/cl/128136, 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 https://golang.org/cl/128555), 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

@timtadh

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.

@rsc

This comment has been minimized.

Contributor

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

@timtadh

This comment has been minimized.

timtadh commented Aug 17, 2018

thanks!

@bcmills

This comment has been minimized.

Member

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