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

Jump to bottom

cmd/go: go get -u on a single module results in indirect modules being updated too #28156

Closed
jsternberg opened this issue Oct 11, 2018 · 1 comment
Closed

cmd/go: go get -u on a single module results in indirect modules being updated too #28156

jsternberg opened this issue Oct 11, 2018 · 1 comment
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@jsternberg
Copy link

What did you do?

I have a project that uses go modules. It includes in it an indirect dependency on golang.org/x/tools. I have a second project that uses the first project. It has a direct dependency on golang.org/x/tools.

I run go get -u <first module> and it updates both the module I specify and golang.org/x/tools even though the first module has not updated its dependency.

It can be seen in the commits for the project here: https://github.com/jsternberg/go-get-update

Inside of that repository, the output of go mod graph is included at each step.

What did you expect to see?

I did not expect to see golang.org/x/tools updated. I only expected github.com/influxdata/flux to be on the updated list or, if tools was updated, to be updated to the version in flux rather than the latest.

What did you see instead?

The golang.org/x/tools project always becomes the latest. This is most noticeable with golang.org/x/tools because it is actively being worked on, but I have noticed this with other implicit dependencies.

At the moment, I think it's only with this very specific relationship where a dependency is not a module and it is included implicitly in a module and included explicitly in a third module. We've experienced some weird update behaviors and are unsure about which ones are bugs and which ones are us learning modules. I think this one is a bug based on my current understanding of modules though.

When updating, I also see this output which is strange considering that only a single module is being updated:

jsternberg:[~/g/s/g/j/go-get-update] $ (master) go get -u github.com/influxdata/flux
go: finding github.com/influxdata/flux latest
go: finding github.com/mattn/go-tty latest
go: finding github.com/gonum/integrate latest
go: finding github.com/prometheus/procfs latest
go: finding golang.org/x/sync latest
go: finding github.com/gonum/mathext latest
go: finding github.com/gonum/internal latest
go: finding github.com/influxdata/tdigest latest
go: finding github.com/prometheus/common latest
go: finding github.com/prometheus/client_model latest
go: finding golang.org/x/sys latest
go: finding github.com/gonum/diff latest
go: finding github.com/gonum/floats latest
go: finding github.com/pkg/term latest
go: finding github.com/gonum/stat latest
go: finding github.com/beorn7/perks latest
go: finding github.com/andreyvit/diff latest
go: finding golang.org/x/net latest
go: finding github.com/gonum/lapack latest
go: finding github.com/gonum/blas latest
go: finding golang.org/x/tools latest
go: finding github.com/gonum/matrix latest
go: finding gopkg.in/check.v1 latest

System details

go version go1.11.1 darwin/amd64
GOARCH="amd64"
GOBIN="/Users/jsternberg/go/pkg/bin/github.com/jsternberg/go-get-update"
GOCACHE="/Users/jsternberg/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/jsternberg/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.1/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/jsternberg/go/src/github.com/jsternberg/go-get-update/go.mod"
GOROOT/bin/go version: go version go1.11.1 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.11.1
uname -v: Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.14
BuildVersion:	18A391
lldb --version: lldb-1000.11.37.1
  Swift-4.2
@SamWhited SamWhited added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. modules labels Oct 17, 2018
This was referenced Oct 23, 2018
Closed
Closed
@bcmills
Copy link
Contributor

bcmills commented Oct 26, 2018

go get -u <pkg> has meant “upgrade <pkg> and its transitive dependencies” since long before modules. We aren't changing that for module mode: the idea is to make the existing go get commands module-aware, not to replace them with an entirely different set.

At the moment there is a bit of ambiguity as to whether “transitive dependencies” should apply to packages or modules (#26902), but I suspect that it does not change the outcome for your example.

go get github.com/influxdata/flux@latest is probably the clearest way to express that you want to upgrade only github.com/influxdata/flux.

@bcmills bcmills closed this as completed Oct 26, 2018
@bcmills bcmills mentioned this issue Oct 26, 2018
Closed
@bcmills bcmills mentioned this issue Mar 1, 2019
Closed
@golang golang locked and limited conversation to collaborators Oct 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@SamWhited @jsternberg @bcmills @gopherbot