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: regression of module resolution behaviour #32152

Closed
rogpeppe opened this issue May 20, 2019 · 5 comments
Closed

cmd/go: regression of module resolution behaviour #32152

rogpeppe opened this issue May 20, 2019 · 5 comments

Comments

@rogpeppe
Copy link
Contributor

@rogpeppe rogpeppe commented May 20, 2019

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

$ go version
go version devel +ab724d43ef Mon May 20 20:58:14 2019 +0000 linux/amd64

On tip, module pseudo-version resolution does not seem to work correctly in some cases where it works OK under Go 1.12.

I'm using git version 2.21.0.

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

go env Output
$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/rog/.cache/go-build"
GOENV="/home/rog/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/rog/src/go"
GOPROXY="direct"
GOROOT="/home/rog/go"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/home/rog/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/rog/go/src/go.mod"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build080092268=/tmp/go-build -gno-record-gcc-switches"

Here's a program that resolves a dependency to a pseudo-version: https://play.golang.org/p/C-wGtbN2TwA

Under Go 1.12 (or the playground) produces this result:

github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc

This is expected. Commit d8f796af33cc has v1.1.1 in its history, so the pseudo-version should include the latest predecessor version.

Under tip, I see this result:

github.com/davecgh/go-spew v0.0.0-20180830191138-d8f796af33cc

It seems that the logic for determining predecessor versions is no longer working correctly.

@rogpeppe rogpeppe added the modules label May 20, 2019
@rogpeppe

This comment has been minimized.

Copy link
Contributor Author

@rogpeppe rogpeppe commented May 20, 2019

Here's another test case that doesn't do the right thing AFAICS, although this one fails under Go 1.12 too:

https://play.golang.org/p/qDuD3BjVlmx

Note that commit 623b5a2f4d2a has v2.0.5 in its history, so I think the resulting version should be v2.0.6-0.20181027085611-623b5a2f4d2a+incompatible, not v0.0.0-20181027085611-623b5a2f4d2a.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented May 20, 2019

I can't reproduce the observed behavior with a clean module cache:

example.com$ gotip version
go version devel +ab724d43 Mon May 20 20:58:14 2019 +0000 linux/amd64

example.com$ gotip mod init example.com
go: creating new go.mod: module example.com

example.com$ gotip get github.com/davecgh/go-spew@d8f796af33cc
go: finding github.com/davecgh/go-spew d8f796af33cc
go: downloading github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc
go: extracting github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc

I suspect that you've got a v0.0.0-* entry in your module cache, perhaps due to an older pseudo-version specified in the (transitive) requirements of some module you've built previously. If so, that would make this another instance of #27171. Could you confirm?

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented May 20, 2019

The v2.0.6-[…]+incompatible issue is #29262.

@rogpeppe

This comment has been minimized.

Copy link
Contributor Author

@rogpeppe rogpeppe commented May 21, 2019

I've just tried it again this morning and I can no longer reproduce the issue, sadly. I haven't changed my cache settings. There's something odd going on. For future reference though, when you talk about the "module cache", you're talking about what's in $GOPATH/pkg, not $GOCACHE, right?

I'll close the issue for now.

@rogpeppe rogpeppe closed this May 21, 2019
@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented May 21, 2019

For future reference though, when you talk about the "module cache", you're talking about what's in $GOPATH/pkg, not $GOCACHE, right?

Correct.

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