cmd/go: 'go get <pkg>@<tag>' should not fall back to 'latest' if <tag> does not provide <pkg> #29121

kidlj · 2018-12-06T11:11:07Z

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

The text was updated successfully, but these errors were encountered:

kidlj · 2018-12-06T11:22:28Z

And, may I ask, why does go get download another newer version same package, or the latest version when wanted version requested?

$ 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: finding k8s.io/apimachinery latest
go: downloading k8s.io/apimachinery v0.0.0-20181204150028-eb8c8024849b

bcmills · 2018-12-06T21:50:00Z

kubernetes-1.12.3 is not a valid semantic version (per https://semver.org), so the go command treats it as just another tag, and uses the usual algorithm to try to find a valid semantically-versioned name for it.

That tag corresponds to commit d082d5923d3cc0bfbb066ee5fbdea3d0ca79acf8, which happens to
have v2.0.0-alpha.0-1296-gd082d592 as a (transitive) parent:

~/src/k8s.io/client-go$ git describe --tags d082d5923d3cc0bfbb066ee5fbdea3d0ca79acf8 --match 'v*'
v2.0.0-alpha.0-1296-gd082d592

So the go command synthesizes a pseudo-version for an arbitrary commit after v2.0.0-alpha.0. That is working as designed.

bcmills · 2018-12-06T21:59:52Z

In the case of apimachinery, there are no valid semantically-versioned tags in the history, so go picks a pseudo-version appropriate to a repository without any semantically-versioned tags — that is, v0.0.0.

~/src/k8s.io/apimachinery$ git rev-list -n 1 kubernetes-1.12.3
eddba98df674a16931d2d4ba75edc3a389bf633a

~/src/k8s.io/apimachinery$ git describe --match 'v*' --tags eddba98df674a16931d2d4ba75edc3a389bf633a
fatal: No names found, cannot describe anything.

When you run go get k8s.io/apimachinery@kubernetes-1.12.3, you are asking go get to resolve the package k8s.io/apimachinery, which does not exist at that revision. It appears to be trying latest instead, but that is a bug.

$ go mod init golang.org/issue/scratch
go: creating new go.mod: module golang.org/issue/scratch

$ go get -m k8s.io/apimachinery@kubernetes-1.12.3
go: finding k8s.io/apimachinery kubernetes-1.12.3

$ go list -m all
golang.org/issue/scratch
k8s.io/apimachinery v0.0.0-20181126123746-eddba98df674

$ 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
go: finding k8s.io/apimachinery latest
go: downloading k8s.io/apimachinery v0.0.0-20181204150028-eb8c8024849b
go: extracting k8s.io/apimachinery v0.0.0-20181204150028-eb8c8024849b

kidlj · 2018-12-07T01:47:00Z

kubernetes-1.12.3 is not a valid semantic version (per https://semver.org), so the go command treats it as just another tag, and uses the usual algorithm to try to find a valid semantically-versioned name for it.

That tag corresponds to commit d082d5923d3cc0bfbb066ee5fbdea3d0ca79acf8, which happens to
have v2.0.0-alpha.0-1296-gd082d592 as a (transitive) parent:
~/src/k8s.io/client-go$ git describe --tags d082d5923d3cc0bfbb066ee5fbdea3d0ca79acf8 --match 'v*'
v2.0.0-alpha.0-1296-gd082d592
So the go command synthesizes a pseudo-version for an arbitrary commit after v2.0.0-alpha.0. That is working as designed.

Thanks. And I found the official doc explaining this: https://golang.org/cmd/go/#hdr-Pseudo_versions

bcmills · 2018-12-12T14:58:24Z

See also #27102.

kidlj · 2018-12-13T04:06:32Z

When you run go get k8s.io/apimachinery@kubernetes-1.12.3, you are asking go get to resolve the package k8s.io/apimachinery, which does not exist at that revision. It appears to be trying latest instead, but that is a bug.

Hi, @bcmills , I still have a question:

Since go packages are not version-aware, I'm requesting k8s.io/apimachinery with a version mark(which is @kubernetes-1.12.3), so I guess I'm asking go get to resolve a module. Is this correct? Thanks.

bcmills · 2018-12-13T13:27:57Z

Since go packages are not version-aware, […] I guess I'm asking go get to resolve a module. Is this correct?

That's a really great question, because it is a bit funny to mix packages and module-versions like that. 🙂

As implemented, what it means today is “get me some module with tag kubernetes-1.12.3 that contains the package k8s.io/apimachinery”. We don't know exactly which module that is ahead of time, but in most cases it ends up being unambiguous: overlapping modules are rare, and overlapping versions of overlapping modules are even more rare.

kidlj · 2018-12-13T16:10:42Z

@bcmills , through go help module-get doc and your explanation, I just found that whether in module-aware mode or not, go get should always get a package.

Usage: go get [-d] [-m] [-u] [-v] [-insecure] [build flags] [packages]

Earlier I thought that in module-aware mode or when a module version is specified get get should get a module.

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

So continuing the k8s.io/apimachinery example, 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? Or there is another canonical way to achieve this?

bcmills · 2018-12-13T16:39:44Z

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.

jwieringa · 2019-05-13T18:08:48Z

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

tbpg · 2019-05-17T19:40:57Z

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?

bcmills · 2019-05-31T16:48:36Z

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$

thepudds · 2019-05-31T18:34:36Z

@jwieringa I think Bryan tried the specific example you reported here, but I would be curious to hear if this is generally working for you on the tip version of Go (e.g,. maybe on a related example you might already have).

go get golang.org/dl/gotip && gotip download is a handy way to try with the latest from tip / master.

jwieringa · 2019-05-31T20:13:01Z

@thepudds Thanks for the gotip pointer, that is handy!

I've observed the get, build, and test commands work successfully. Thanks!

I am observing gotip mod tidy fetch the latest version of the gonum module and not respect the version set in gotip get <package>@<revision>. You can see how I reached this state in detail in RadiusNetworks/lda#7 (comment)

I expected mod tidy to respect versions. Should it be respecting versions?

$ gotip version
go version devel +2165452 Fri May 31 11:26:23 2019 +0000 darwin/amd64

$ gotip mod tidy
go: finding gonum.org/v1/netlib latest

$ git diff
diff --git a/Iris-data-LDA-graph.png b/Iris-data-LDA-graph.png
index 35c4e34..afdc6a4 100644
Binary files a/Iris-data-LDA-graph.png and b/Iris-data-LDA-graph.png differ
diff --git a/go.mod b/go.mod
index 6132263..af6e02f 100644
--- a/go.mod
+++ b/go.mod
@@ -3,6 +3,7 @@ module github.com/RadiusNetworks/lda
 go 1.13

 require (
-       gonum.org/v1/gonum v0.0.0-20180816165407-929014505bf4
+       gonum.org/v1/gonum v0.0.0-20190331200053-3d26580ed485
+       gonum.org/v1/netlib v0.0.0-20190331212654-76723241ea4e // indirect
        gonum.org/v1/plot v0.0.0-20190515093506-e2840ee46a6b
 )
diff --git a/go.sum b/go.sum
index af30dfd..6e0105d 100644
--- a/go.sum
+++ b/go.sum
@@ -1,3 +1,4 @@
+github.com/BurntSushi/xgb v0.0.0-20160522181843-27f122750802/go.mod h1:IVnqGOEym/WlBOVXweHU+Q+/VP0lqqI8lqeDx9IjBqo=
 github.com/ajstarks/svgo v0.0.0-20180226025133-644b8db467af h1:wVe6/Ea46ZMeNkQjjBW6xcqyQA/j5e0D6GytH95g0gQ=
 github.com/ajstarks/svgo v0.0.0-20180226025133-644b8db467af/go.mod h1:K08gAheRH3/J6wwsYMMT4xOr94bZjxIelGM0+d/wbFw=
 github.com/fogleman/gg v1.2.1-0.20190220221249-0403632d5b90 h1:WXb3TSNmHp2vHoCroCIB1foO/yQ36swABL8aOVeDpgg=
@@ -6,15 +7,39 @@ github.com/golang/freetype v0.0.0-20170609003504-e2365dfdc4a0 h1:DACJavvAHhabrF0
 github.com/golang/freetype v0.0.0-20170609003504-e2365dfdc4a0/go.mod h1:E/TSTwGwJL78qG/PmXZO1EjYhfJinVAhrmmHX6Z8B9k=
 github.com/jung-kurt/gofpdf v1.0.3-0.20190309125859-24315acbbda5 h1:PJr+ZMXIecYc1Ey2zucXdR73SMBtgjPgwa31099IMv0=
 github.com/jung-kurt/gofpdf v1.0.3-0.20190309125859-24315acbbda5/go.mod h1:7Id9E/uU8ce6rXgefFLlgrJj/GYY22cpxn+r32jIOes=
+github.com/remyoudompheng/bigfft v0.0.0-20170806203942-52369c62f446/go.mod h1:uYEyJGbgTkfkS4+E/PavXkNJcbFIpEtjt2B0KDQ5+9M=
+golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
 golang.org/x/exp v0.0.0-20180321215751-8460e604b9de/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
+golang.org/x/exp v0.0.0-20180807140117-3d87b88a115f h1:9kQ594xxPWRNKfTOnPjPcgrIJ19zM3ic57aI7PbMyAA=
 golang.org/x/exp v0.0.0-20180807140117-3d87b88a115f/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
+golang.org/x/exp v0.0.0-20190125153040-c74c464bbbf2/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
+golang.org/x/exp v0.0.0-20190312203227-4b39c73a6495 h1:I6A9Ag9FpEKOjcKrRNjQkPHawoXIhKyTGfvvjFAiiAk=
+golang.org/x/exp v0.0.0-20190312203227-4b39c73a6495/go.mod h1:ZjyILWgesfNpC6sMxTJOJm9Kp84zZh5NQWvqDGG3Qr8=
 golang.org/x/image v0.0.0-20180708004352-c73c2afc3b81 h1:00VmoueYNlNz/aHIilyyQz/MHSqGoWJzpFv/HW8xpzI=
 golang.org/x/image v0.0.0-20180708004352-c73c2afc3b81/go.mod h1:ux5Hcp/YLpHSI86hEcLt0YII63i6oz57MZXIpbrjZUs=
+golang.org/x/image v0.0.0-20190227222117-0694c2d4d067 h1:KYGJGHOQy8oSi1fDlSpcZF0+juKwk/hEMv5SiwHogR0=
+golang.org/x/image v0.0.0-20190227222117-0694c2d4d067/go.mod h1:kZ7UVZpmo3dzQBMxlp+ypCbDeSB+sBbTgSJuh5dn5js=
+golang.org/x/mobile v0.0.0-20190312151609-d3739f865fa6/go.mod h1:z+o9i4GpDbdi3rU15maQ/Ox0txvL9dWGYEHz965HBQE=
+golang.org/x/net v0.0.0-20190311183353-d8887717615a/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
+golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
+golang.org/x/sys v0.0.0-20190312061237-fead79001313/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
 golang.org/x/tools v0.0.0-20180525024113-a5b4c53f6e8b/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
-gonum.org/v1/gonum v0.0.0-20180802201828-73ea1e732937 h1:CYrmfhpCQPcI0uTwJ6mxYIUsGnXllAvY2rLrTI2InpQ=
-gonum.org/v1/gonum v0.0.0-20180802201828-73ea1e732937/go.mod h1:Y+Yx5eoAFn32cQvJDxZx5Dpnq+c3wtXuadVZAcxbbBo=
+golang.org/x/tools v0.0.0-20190206041539-40960b6deb8e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
+golang.org/x/tools v0.0.0-20190312151545-0bb0c0a6e846/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
 gonum.org/v1/gonum v0.0.0-20180816165407-929014505bf4 h1:nYxTaCPaVoJbxx+vMVnsFb6kw5+6aJCx52m/lmM/Vog=
 gonum.org/v1/gonum v0.0.0-20180816165407-929014505bf4/go.mod h1:Y+Yx5eoAFn32cQvJDxZx5Dpnq+c3wtXuadVZAcxbbBo=
+gonum.org/v1/gonum v0.0.0-20190331200053-3d26580ed485 h1:OB/uP/Puiu5vS5QMRPrXCDWUPb+kt8f1KW8oQzFejQw=
+gonum.org/v1/gonum v0.0.0-20190331200053-3d26580ed485/go.mod h1:2ltnJ7xHfj0zHS40VVPYEAAMTa3ZGguvHGBSJeRWqE0=
+gonum.org/v1/netlib v0.0.0-20190313105609-8cb42192e0e0/go.mod h1:wa6Ws7BG/ESfp6dHfk7C6KdzKA7wR7u/rKwOGE66zvw=
+gonum.org/v1/netlib v0.0.0-20190331212654-76723241ea4e h1:jRyg0XfpwWlhEV8mDfdNGBeSJM2fuyh9Yjrnd8kF2Ts=
+gonum.org/v1/netlib v0.0.0-20190331212654-76723241ea4e/go.mod h1:kS+toOQn6AQKjmKJ7gzohV1XkqsFehRA2FbsbkopSuQ=
 gonum.org/v1/plot v0.0.0-20190515093506-e2840ee46a6b h1:Qh4dB5D/WpoUUp3lSod7qgoyEHbDGPUWjIbnqdqqe1k=
 gonum.org/v1/plot v0.0.0-20190515093506-e2840ee46a6b/go.mod h1:Wt8AAjI+ypCyYX3nZBvf6cAIx93T+c/OS2HFAYskSZc=
+modernc.org/cc v1.0.0/go.mod h1:1Sk4//wdnYJiUIxnW8ddKpaOJCF37yAdqYnkxUpaYxw=
+modernc.org/golex v1.0.0/go.mod h1:b/QX9oBD/LhixY6NDh+IdGv17hgB+51fET1i2kPSmvk=
+modernc.org/mathutil v1.0.0/go.mod h1:wU0vUrJsVWBZ4P6e7xtFJEhFSNsfRLJ8H458uRjg03k=
+modernc.org/strutil v1.0.0/go.mod h1:lstksw84oURvj9y3tn8lGvRxyRC1S2+g5uuIzNfIOBs=
+modernc.org/xc v1.0.0/go.mod h1:mRNCo0bvLjGhHO9WsyuKVU4q0ceiDDDoEeWDJHrNx8I=
+rsc.io/pdf v0.1.1 h1:k1MczvYDUvJBe93bYd7wrZLLUEcLZAuF824/I4e5Xr4=
 rsc.io/pdf v0.1.1/go.mod h1:n8OzWcQ6Sp37PL01nO98y4iUCRdTGarVfzxY20ICaU4=

thepudds · 2019-05-31T20:30:08Z

go mod tidy ensures your current go.mod reflects the dependency requirements for all possible combinations of OS, architecture, and build tags. In contrast, other commands like go build and go test only update go.mod to provide the packages imported by the requested packages under the current GOOS, GOARCH, and build tags (which is one reason go mod tidy might add requirements that were not added by go build or similar).

That might be part of the explanation?

Worth trying the troubleshooting steps here to see if that more concretely explains why the version changes:

https://github.com/golang/go/wiki/Modules#what-can-i-check-if-i-am-not-seeing-the-expected-version-of-a-dependency

bcmills · 2019-05-31T20:58:00Z

@jwieringa, this issue is specifically about go get. RadiusNetworks/lda#7 is probably the right place to continue the conversation about go mod tidy, but thanks for bringing it to our attention.

jwieringa · 2019-05-31T21:18:06Z

@thepudds @bcmills Thank you for the help and navigating the topics, appreciated!

bcmills changed the title ~~cmd/go: go get <pkg>@<tag> generates wrong version string in go.mod~~ cmd/go: 'go get <pkg>@<tag>' should not fall back to 'latest' if <tag> does not provide <pkg> Dec 6, 2018

bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. modules labels Dec 6, 2018

bcmills added this to the Go1.12 milestone Dec 6, 2018

bcmills mentioned this issue Dec 12, 2018

cmd/go: 'go get github.com/Azure/azure-sdk-for-go@v5.0.0-beta' silently gets 'v20.1.0' instead #27627

Closed

bcmills self-assigned this Dec 12, 2018

bcmills mentioned this issue Dec 21, 2018

cmd/go: modules unable to fetch from commit, only from release #29196

Closed

andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019

This was referenced Mar 7, 2019

cmd/go: 'looping trying to add package' when running 'mod tidy' with a package not found in the containing module #30394

Closed

cmd/go: proposal: go get path@version should fail if version cannot be exactly satisfied #30717

Closed

bcmills added the release-blocker label May 14, 2019

bcmills closed this as completed May 31, 2019

jwieringa mentioned this issue May 31, 2019

Add Go module RadiusNetworks/lda#7

Merged

bcmills mentioned this issue Jul 12, 2019

cmd/go: go get tries to download non-existing commit #33076

Closed

zonotope mentioned this issue Sep 10, 2019

use the latest ipld-cbor lib quorumcontrol/chaintree#72

Closed

golang locked and limited conversation to collaborators May 30, 2020

gopherbot added the FrozenDueToAge label May 30, 2020

rsc unassigned bcmills Jun 23, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: 'go get <pkg>@<tag>' should not fall back to 'latest' if <tag> does not provide <pkg> #29121

cmd/go: 'go get <pkg>@<tag>' should not fall back to 'latest' if <tag> does not provide <pkg> #29121

kidlj commented Dec 6, 2018

kidlj commented Dec 6, 2018 •

edited

bcmills commented Dec 6, 2018

bcmills commented Dec 6, 2018

kidlj commented Dec 7, 2018

bcmills commented Dec 12, 2018

kidlj commented Dec 13, 2018

bcmills commented Dec 13, 2018 •

edited

kidlj commented Dec 13, 2018

bcmills commented Dec 13, 2018

jwieringa commented May 13, 2019 •

edited

tbpg commented May 17, 2019

bcmills commented May 31, 2019

thepudds commented May 31, 2019

jwieringa commented May 31, 2019

thepudds commented May 31, 2019 •

edited

bcmills commented May 31, 2019

jwieringa commented May 31, 2019

cmd/go: 'go get <pkg>@<tag>' should not fall back to 'latest' if <tag> does not provide <pkg> #29121

cmd/go: 'go get <pkg>@<tag>' should not fall back to 'latest' if <tag> does not provide <pkg> #29121

Comments

kidlj commented Dec 6, 2018

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

kidlj commented Dec 6, 2018 • edited

bcmills commented Dec 6, 2018

bcmills commented Dec 6, 2018

kidlj commented Dec 7, 2018

bcmills commented Dec 12, 2018

kidlj commented Dec 13, 2018

bcmills commented Dec 13, 2018 • edited

kidlj commented Dec 13, 2018

bcmills commented Dec 13, 2018

jwieringa commented May 13, 2019 • edited

tbpg commented May 17, 2019

bcmills commented May 31, 2019

thepudds commented May 31, 2019

jwieringa commented May 31, 2019

thepudds commented May 31, 2019 • edited

bcmills commented May 31, 2019

jwieringa commented May 31, 2019

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

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

kidlj commented Dec 6, 2018 •

edited

bcmills commented Dec 13, 2018 •

edited

jwieringa commented May 13, 2019 •

edited

thepudds commented May 31, 2019 •

edited