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: modules not keeping downgraded version of dependency #34794

Closed
astockwell opened this issue Oct 9, 2019 · 4 comments
Closed

cmd/go: modules not keeping downgraded version of dependency #34794

astockwell opened this issue Oct 9, 2019 · 4 comments

Comments

@astockwell
Copy link

@astockwell astockwell commented Oct 9, 2019

What version of Go are you using (go version)?

$ go version
go version go1.13.1 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/astockwell/Library/Caches/go-build"
GOENV="/Users/astockwell/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY="scm.dignityhealth.org"
GONOSUMDB="scm.dignityhealth.org"
GOOS="darwin"
GOPATH="/Users/astockwell/go"
GOPRIVATE="scm.dignityhealth.org"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/0j/vc0d3b_n0xd5czs9khsph0v40000gn/T/go-build970075728=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

  • Started with an existing project, converted it to go modules (go.mod, go.sum).
  • Verified building and testing worked.
  • Realized an update to a dependency (of a dependency) broke my project
  • Observed my project's go.mod require'd github.com/jinzhu/gorm v1.9.11
  • Ran go get to an older version (in this case go get github.com/jinzhu/gorm@v1.9.8)
  • Observed my project's go.mod now denoted github.com/jinzhu/gorm v1.9.8

At this point, any go commands I run, whether go build or go mod commands, overwrite my go.mod file and revert the dependency in go.mod to v1.9.11 (the latest), as well as build with it.

What did you expect to see?

I expected the project to leave the dependency as I pinned it (at v1.9.8), and to build with it at that tagged version.

What did you see instead?

The build happened with the latest version of the dependency (including the breaking update), and my go.mod/go.sum files were overwritten to the latest version of the dependency.

@andybons andybons changed the title Go modules not keeping downgraded version of dependency cmd/go: modules not keeping downgraded version of dependency Oct 9, 2019
@andybons andybons added this to the Unplanned milestone Oct 9, 2019
@andybons

This comment has been minimized.

Copy link
Member

@andybons andybons commented Oct 9, 2019

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 9, 2019

The go.mod file specifies minimum versions — it does not pin them.

For most operations, the go command updates the go.mod file to account for the requirements imposed by transitive dependencies. So presumably one of your transitive dependencies require s github.com/jinzhu/gorm v1.9.11, and when you run go get github.com/jinzhu/gorm@v1.9.8 that transitive dependency is removed entirely (because every released version of it requires v1.9.8 or higher).

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 9, 2019

We do need better diagnostics for what's going on, though. Right now it's mostly just go mod graph, which emits a lot of data — and most of that data is not relevant to the problem at hand.

  • #33124 requests an explicit command to explain the selected versions.
  • #33284 requests that we log the reasons for version changes to stderr when they occur.

I suspect that the latter would be more useful here.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 9, 2019

Duplicate of #33284

@bcmills bcmills marked this as a duplicate of #33284 Oct 9, 2019
@bcmills bcmills closed this Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.