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: get -u updates more in module mode than GOPATH mode #26902

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

Comments

Projects
None yet
3 participants
@bcmills
Copy link
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.

Copy link

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.

Copy link
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.

Copy link

timtadh commented Aug 17, 2018

thanks!

@bcmills

This comment has been minimized.

Copy link
Member Author

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.)

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Mar 7, 2019

An observation: currently, if I run go get -u (without arguments) in github.com/bcmills/goissues, I get upgrades to a rather large set of transitive dependencies.

go mod tidy removes most of those upgrades, because they aren't even remotely relevant to the build.

So one nice property for go get -u to have would be preservation of tideness: if the module is already tidy, then go get -u should not make it untidy.

@rsc rsc changed the title cmd/go: clarify which dependencies are updated by 'get -u' without '-m' cmd/go: get -u is updates much more in module mode than GOPATH more Mar 14, 2019

@rsc

This comment has been minimized.

Copy link
Contributor

rsc commented Mar 14, 2019

In GOPATH mode get -u only applied to the transitive dependencies of a set of packages. In module mode it is always the transitive dependencies of the module graph. It's possible that we should preserve a "just update the deps of this target set".

@rsc rsc changed the title cmd/go: get -u is updates much more in module mode than GOPATH more cmd/go: get -u updates much more in module mode than GOPATH more Mar 14, 2019

@rsc rsc changed the title cmd/go: get -u updates much more in module mode than GOPATH more cmd/go: get -u updates much in module mode than GOPATH mode Mar 14, 2019

@rsc rsc changed the title cmd/go: get -u updates much in module mode than GOPATH mode cmd/go: get -u updates more in module mode than GOPATH mode Mar 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.