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: no clear "go get" message when requested version doesn't match suffix #31498

Open
firelizzard18 opened this issue Apr 16, 2019 · 6 comments

Comments

Projects
None yet
4 participants
@firelizzard18
Copy link

commented Apr 16, 2019

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

$ go version
go version go1.12 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
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/me/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/me/Source/Go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/tmp/test/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/qx/064gkvrd7bl0trt43gd434f0zm0rjy/T/go-build739499749=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

$ go get gitlab.example.com/my/pkg@v2.1.0

What did you expect to see?

go.mod:

module test

go 1.12

require gitlab.example.com/my/pkg v2.1.0

What did you see instead?

module test

go 1.12

require gitlab.example.com/my/pkg v0.0.0-20190416182416-8556b6232906

I don't understand why go get is not respecting my tag. The correct tags exist. v1.6.1 works fine, but v2.0.0 and v2.1.0 don't work.

$ git ls-remote --tags git@gitlab.example.com:my/pkg .git
...
a4ce364216755764766eb7d75518f8bf227cd106        refs/tags/v1.6.1
b2b3bfc0416ab40e30042683b9128d38b8c2eefc        refs/tags/v1.6.1^{}
be9d7c7b6e3fc68aae49cfbdd7ff78c2372b4d4c        refs/tags/v2.0.0
aa7975ba93ff643c24f6f949988ddf61ec637b90        refs/tags/v2.0.0^{}
f47456c7276fc677fdc41e18c51b3c56c7e365c2        refs/tags/v2.0.1
0209bae56a88afe277edf8ec12a10d0e2f33be17        refs/tags/v2.0.1^{}
e96fe2a02d7e4559f3d86520d7643faaec3e6c7e        refs/tags/v2.1.0
8556b6232906717785033de712aa27e4cd7a4600        refs/tags/v2.1.0^{}
@jayconrod

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2019

Versions that start with v2 or later don't belong to the same module as v0 or v1 versions. They would belong to gitlab.example.com/my/pkg/v2. The major version suffix is required.

We should provide a clear diagnostic message for this.

@jayconrod jayconrod changed the title cmd/go: go get not respecting version tag cmd/go: no clear "go get" message when requested version doesn't match suffix Apr 16, 2019

@jayconrod jayconrod self-assigned this Apr 16, 2019

@jayconrod jayconrod added this to the Go1.13 milestone Apr 16, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Apr 24, 2019

This might be a duplicate of #30499. (Not entirely clear to me whether the problems occur under the same conditions.)

@jayconrod jayconrod removed their assignment Apr 24, 2019

@jayconrod

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2019

@tbpg is working on this, but I'm not able to assign it to him.

@gopherbot

This comment has been minimized.

Copy link

commented Apr 26, 2019

Change https://golang.org/cl/174180 mentions this issue: cmd/go: error if mismatched major versions causes use of pseudo-version

@gopherbot

This comment has been minimized.

Copy link

commented Apr 30, 2019

Change https://golang.org/cl/173721 mentions this issue: cmd/go: error if mismatched major versions causes use of pseudo-version

@bcmills

This comment has been minimized.

Copy link
Member

commented May 13, 2019

prometheus/prometheus#5356 (comment) is an interesting counter-point to this issue: it appears that some maintainers are already intentionally using mismatched module paths to avoid SemVer semantics for not-actually-SemVer repositories.

That said, it seems like the pseudo-version we choose in that case should be based on the last v1.*.* tag, not the v0.0.0 prefix that we're seeing today. (Perhaps the observed behavior for prometheus — and possibly for @firelizzard18's example in this issue — is another instance of #27171?)

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.