go: cmd/go: 'go get @' should not fall back to 'latest' if does not provide

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

go version go1.11.2 windows/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
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\kdlij\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=D:/testmod/
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=D:\testclient\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\kdlij\AppData\Local\Temp\go-build439133958=/tmp/go-build -gno-record-gcc-switches

What did you do?

Outside $GOPATH,

kidlj@collie MINGW64 /d/testclient
$ go mod init github.com/kidlj/test
go: creating new go.mod: module github.com/kidlj/test

kidlj@collie MINGW64 /d/testclient
$ cat go.mod
module github.com/kidlj/test

kidlj@collie MINGW64 /d/testclient
$ go get k8s.io/client-go@kubernetes-1.12.3
go: finding k8s.io/client-go kubernetes-1.12.3

kidlj@collie MINGW64 /d/testclient
$ cat go.mod
module github.com/kidlj/test

require k8s.io/client-go v2.0.0-alpha.0.0.20181126152608-d082d5923d3c+incompatible // indirect

What did you expect to see?

In go.mod:

require k8s.io/client-go v0.0.0-alpha.0.0.20181126152608-d082d5923d3c+incompatible // indirect

What did you see instead?

n go.mod:

require k8s.io/client-go v2.0.0-alpha.0.0.20181126152608-d082d5923d3c+incompatible // indirect

The question is:

How is the requested version(@kubernetes-1.12.3), also 20181126152608-d082d5923d3c related with v2.0.0-alpha?

The kubernetes/client-go releases page is here: https://github.com/kubernetes/client-go/tags

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 2
Comments: 17 (10 by maintainers)

Most upvoted comments

This does indeed seem to be fixed at head.

example.com$ gotip version
go version devel +2165452a Fri May 31 11:26:23 2019 +0000 linux/amd64

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

example.com$ gotip get k8s.io/client-go@kubernetes-1.12.3
go: finding k8s.io/client-go kubernetes-1.12.3
go: downloading k8s.io/client-go v0.0.0-20181126152608-d082d5923d3c
go: extracting k8s.io/client-go v0.0.0-20181126152608-d082d5923d3c

example.com$ gotip get k8s.io/apimachinery@kubernetes-1.12.3
go: finding k8s.io/apimachinery kubernetes-1.12.3
go: downloading k8s.io/apimachinery v0.0.0-20181126123746-eddba98df674
go: extracting k8s.io/apimachinery v0.0.0-20181126123746-eddba98df674

example.com$ gotip get gonum.org/v1/gonum@73ea1e732937f96d723d31dc5263d214a275d204
go: finding gonum.org/v1/gonum 73ea1e732937f96d723d31dc5263d214a275d204
go: finding golang.org/x/exp v0.0.0-20180321215751-8460e604b9de
go: finding golang.org/x/tools v0.0.0-20180525024113-a5b4c53f6e8b
go: downloading gonum.org/v1/gonum v0.0.0-20180802201828-73ea1e732937
go: extracting gonum.org/v1/gonum v0.0.0-20180802201828-73ea1e732937

example.com$ go list -m all
example.com
golang.org/x/exp v0.0.0-20180321215751-8460e604b9de
golang.org/x/tools v0.0.0-20180525024113-a5b4c53f6e8b
gonum.org/v1/gonum v0.0.0-20180802201828-73ea1e732937
k8s.io/apimachinery v0.0.0-20181126123746-eddba98df674
k8s.io/client-go v0.0.0-20181126152608-d082d5923d3c

example.com$

bcmills on May 31, 2019

With go version devel +b8c545dc45 Thu May 16 17:42:30 2019 -0400 linux/amd64 I get the following when getting apimachinery:

➜  go get k8s.io/apimachinery@kubernetes-1.12.3
go: finding k8s.io/apimachinery kubernetes-1.12.3
go: downloading k8s.io/apimachinery v0.0.0-20181126123746-eddba98df674
go: extracting k8s.io/apimachinery v0.0.0-20181126123746-eddba98df674

Maybe the issue of falling back to latest was fixed?

tbpg on May 17, 2019

My understanding is that I’ve run into a similar situation using another package, gonum. It appears that gonum.org/v1/gonum is not a package (there are no .go files at gonum.org/v1/gonum) at the commit set in @<revision>.

The following results in fetching the latest when I expected it to fetch @<revision>.

$ go get gonum.org/v1/gonum@73ea1e732937f96d723d31dc5263d214a275d204
go: finding gonum.org/v1/gonum latest

Difference after running go get.

diff --git a/go.mod b/go.mod
index c3a8d01..ecc44de 100644
--- a/go.mod
+++ b/go.mod
@@ -26,7 +26,7 @@ require (
        golang.org/x/image v0.0.0-20180708004352-c73c2afc3b81
        golang.org/x/net v0.0.0-20180417003750-8d16fa6dc9a8
        golang.org/x/sys v0.0.0-20180417080122-b126b21c05a9
-       gonum.org/v1/gonum v0.0.0-20180802201828-73ea1e732937
+       gonum.org/v1/gonum v0.0.0-20190509213835-50179cd3f3f7
        gonum.org/v1/plot v0.0.0-20180724132003-e0f807cd8606
        gopkg.in/yaml.v2 v2.2.1
 )

These two alternatives result in the expected version being set.

$ go get -m gonum.org/v1/gonum@73ea1e732937f96d723d31dc5263d214a275d204

$ go get gonum.org/v1/gonum/mat@73ea1e732937f96d723d31dc5263d214a275d204

It is unclear to me if this is related or if another issue is required. Running go mod tidy results in the gonum module being set to latest thus bumping the gonum/v1/gonum/mat package to latest as well.

$ go get -m gonum.org/v1/gonum@73ea1e732937f96d723d31dc5263d214a275d204
$ go mod tidy

References:

Thanks goes to thepudds in Gopher Slack for the help

jwieringa on May 13, 2019

The implementation is go get always gets a package, and by the way resolves a module to add to go.mod. Is this right?

Close. The -m flag tells it to fetch a module rather than a package. (Without -m the paths are interpreted as package paths, and with -m they are interpreted as module paths.)

If I want to add specific version k8s/apimachinery module to go.mod manually in advance and hope to import all packages under the the module to use this version, I should run get get with -m option, like go get -m k8s.io/apimachinery@kubernetes-1.12.3, right?

Correct.

bcmills on Dec 13, 2018