opened
bcmills
username_0
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 `import`s of a package, or
* “module dependencies” the set of modules that are `require`d 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 @username_2 correctly, (in https://golang.org/cl/128555), he has some other alternative in mind, although I'm not sure which.
cmd/go: clarify which dependencies are updated by 'get -u' without '-m'
issue
created
timtadh
username_1
As a :+1: 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.
comment
created
rsc
username_2
We'll look more carefully at this in Go 1.12.
comment
created
timtadh
username_1
thanks!
comment
created
bcmills
username_0
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`.)
comment
created
bcmills
username_0
An observation: currently, if I run `go get -u` (without arguments) in `github.com/username_0/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.
comment
created
rsc
username_2
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".
comment