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.

Sign up for GitHub

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

Jump to bottom

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

Closed
kidlj opened this issue Dec 6, 2018 · 17 comments
Closed

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

kidlj opened this issue Dec 6, 2018 · 17 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone
Go1.13

Comments

@kidlj
Copy link

kidlj commented Dec 6, 2018

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/[email protected]
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
@kidlj
Copy link
Author

kidlj commented Dec 6, 2018 •
edited
Loading

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/[email protected]
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
Copy link
Contributor

bcmills commented Dec 6, 2018

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
Copy link
Contributor

bcmills commented Dec 6, 2018

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/[email protected], 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/[email protected]
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/[email protected]
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

@bcmills 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 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 bcmills added this to the Go1.12 milestone Dec 6, 2018
@kidlj
Copy link
Author

kidlj commented Dec 7, 2018

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 bcmills mentioned this issue Dec 12, 2018
Closed
@bcmills
Copy link
Contributor

bcmills commented Dec 12, 2018

See also #27102.

@bcmills bcmills self-assigned this Dec 12, 2018
@kidlj
Copy link
Author

kidlj commented Dec 13, 2018

When you run go get k8s.io/[email protected], 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
Copy link
Contributor

bcmills commented Dec 13, 2018 •
edited
Loading

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
Copy link
Author

kidlj commented Dec 13, 2018

@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/[email protected], right? Or there is another canonical way to achieve this?

@bcmills
Copy link
Contributor

bcmills commented Dec 13, 2018

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/[email protected], right?

Correct.

@bcmills bcmills mentioned this issue Dec 21, 2018
Closed
@andybons andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019
This was referenced Mar 7, 2019
Closed
Closed
@jwieringa
Copy link

jwieringa commented May 13, 2019 •
edited
Loading

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
Copy link
Contributor

tbpg commented May 17, 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/[email protected]
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
Copy link
Contributor

bcmills commented May 31, 2019

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/[email protected]
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/[email protected]
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 bcmills closed this as completed May 31, 2019
@thepudds
Copy link
Contributor

@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 jwieringa mentioned this issue May 31, 2019
Merged
@jwieringa
Copy link

@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
Copy link
Contributor

thepudds commented May 31, 2019 •
edited
Loading

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
Copy link
Contributor

bcmills commented May 31, 2019

@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
Copy link

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

@bcmills bcmills mentioned this issue Jul 12, 2019
Closed
@zonotope zonotope mentioned this issue Sep 10, 2019
Closed
@golang golang locked and limited conversation to collaborators May 30, 2020
@rsc rsc unassigned bcmills Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Milestone
Go1.13
Development

No branches or pull requests
7 participants
@kidlj @jwieringa @andybons @bcmills @gopherbot @thepudds @tbpg