cmd/go: go get golang/x/tools/...: no matching versions for query "latest"

[wsc1]

Please answer these questions before submitting your issue. Thanks!

What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

go get golang.org/x/tools/...

What did you expect to see?

success

What did you see instead?

⎣ ⇨ go get -u -v golang.org/x/tools/...
Fetching https://golang.org/x/tools?go-get=1
Parsing meta tags from https://golang.org/x/tools?go-get=1 (status code 200)
get "golang.org/x/tools": found meta tag get.metaImport{Prefix:"golang.org/x/tools", VCS:"git", RepoRoot:"https://go.googlesource.com/tools"} at https://golang.org/x/tools?go-get=1
go: finding golang.org/x/tools/... latest
Fetching https://golang.org/x/tools?go-get=1
Parsing meta tags from https://golang.org/x/tools?go-get=1 (status code 200)
get "golang.org/x/tools": found meta tag get.metaImport{Prefix:"golang.org/x/tools", VCS:"git", RepoRoot:"https://go.googlesource.com/tools"} at https://golang.org/x/tools?go-get=1
go: finding golang.org/x/tools latest
Fetching https://golang.org/x?go-get=1
Parsing meta tags from https://golang.org/x?go-get=1 (status code 200)
Fetching https://golang.org?go-get=1
Parsing meta tags from https://golang.org?go-get=1 (status code 200)
go get golang.org/x/tools/...: no matching versions for query "latest"

System details

go version go1.11 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/scott/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/scott/Dev/zic"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/scott/Dev/zic/src/zikichombo.org/sound/go.mod"
GOROOT/bin/go version: go version go1.11 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.11
uname -v: Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.13.6
BuildVersion:	17G65
lldb --version: lldb-902.0.79.7
  Swift-4.1

[bradfitz]

Do you have GO111MODULE set to "on" ?

[wsc1]

yes, it was. GO111MODULE=off works ok.

Also, GOMOD was set, which I think should mean it was enabled by some mechanism or other.

[rkuska]

Same is happening here:

$ go get -u github.com/go-critic/go-critic/...                                                                                                                                                                                                                
go: finding github.com/go-critic/go-critic/... latest
go: finding github.com/go-critic/go-critic latest
go get github.com/go-critic/go-critic/...: no matching versions for query "latest"                                                                                                                                                                                                                
$ go version                                  
go version go1.11 darwin/amd64

[ivanalejandro0]

I had the same (or very similar) problem building a module and using GO111MODULE=off wasn't an option for me since I wanted to use modules.
I solved this running go clean -modcache.

[bcmills]

I think the go tool is ending up interpreting the /... as part of the package path instead of a pattern.

Note that in module mode, ... patterns match packages in active modules, so it doesn't really make sense to go get -u one of those patterns unless you've already got those packages in your module dependencies. It would be helpful to see the output of go list golang.org/x/tools/... or go list github.com/go-critic/go-critic/... before you ran go get -u.

[bcmills]

@ivanalejandro0 I would be surprised if an issue fixable by go clean -modcache is the same as the one involving ... patterns.

[ivanalejandro0]

@ivanalejandro0 I would be surprised if an issue fixable by go clean -modcache is the same as the one involving ... patterns.

Yeah, I agree.
My problem didn't involve any ..., but @wsc1 said that with "GO111MODULE=off works ok", so I figured it may be worth mentioning.

[cloudlena]

I can confirm @rkuska's issue with go-critic and have it documented in this Travis build.

[thepudds]

I've seen this error in the wild, given some packages include go get foo/... in their install instructions.

That said, the official documentation seems to claim that this works. In particular, go get golang.org/x/perf/cmd/... is actually cited as example in the official documentation for 'Module aware go get', but if you try that example from the doc, it fails with error no matching versions for query "latest":

From https://tip.golang.org/cmd/go/#hdr-Module_aware_go_get

Note that package patterns are allowed and are expanded after resolving the module versions. For example, 'go get golang.org/x/perf/cmd/...' adds the latest golang.org/x/perf and then installs the commands in that latest version.

Here is that example from the doc from scratch:

$ mkdir -p /tmp/scratchpad/gogetellipsis
$ cd /tmp/scratchpad/gogetellipsis
$ go mod init example.com/me/hello
$ go get golang.org/x/perf/cmd/...
go: finding golang.org/x/perf/cmd/... latest
go: finding golang.org/x/perf/cmd latest
go: finding golang.org/x/perf latest
go get golang.org/x/perf/cmd/...: no matching versions for query "latest"

Note that you can get it to work though if you first do go get golang.org/x/perf/cmd/benchstat, and then repeat the exact previously failing command.

Continuing prior example:

$ ls $GOPATH/bin/bench* | wc -l
0

# install benchstat first
$ go get golang.org/x/perf/cmd/benchstat
go: finding golang.org/x/perf/cmd/benchstat latest
go: finding golang.org/x/perf/cmd latest
go: finding golang.org/x/perf latest

# previously failing command now works (and also installs benchsave)
$ go get golang.org/x/perf/cmd/...
go: finding golang.org/x/perf latest
go: finding golang.org/x/oauth2 latest
go: finding golang.org/x/oauth2/google latest
go: finding golang.org/x/net/context/ctxhttp latest
go: finding golang.org/x/net/context latest
go: finding golang.org/x/net latest
go: finding cloud.google.com/go/compute/metadata latest
go: finding cloud.google.com/go/compute latest

I'm guessing that second example works because golang.org/x/perf becomes part of the active modules prior to doing go get golang.org/x/perf/cmd/....

[frederikcreemers]

Having the same problem with a package providing bindings for v8:

go get github.com/augustoroman/v8: no matching versions for query "latest"

[thepudds]

@bigblind my first guess would be you might be seeing a separate issue, and perhaps one more specific to that /v8 repo. (The fact that it includes /v8 could be confusing the interpretation of semantic import versioning, where the major version for a v2+ module appears in the import path and module path. That said, I had thought pre-existing repos that happened to include /vN were already handled properly, but not sure... so perhaps there is an entirely different problem you are hitting).

The original report in this issue is more related to /... appearing in the go get command, I think, and that original report affects more repos.

Just to get more of the standard details about your environment, etc., and to help track what you are reporting more closely, what would you think about opening a new issue?

You could include the output of go get -v github.com/augustoroman/v8 and maybe go get -x -v github.com/augustoroman/v8. You could also include your git version.

EDIT: the problem reported by @bigblind was in fact a separate issue and due to the /v8, which is tracked in #28435

[thepudds]

@bcmills any brief thoughts on whether or not this is too big for 1.12 at this point?

Also, it is not clear to me if this is working as designed, vs. a bug. For example, from my comment above #27215 (comment):

the official documentation seems to claim that this works. In particular, go get golang.org/x/perf/cmd/... is actually cited as example in the official documentation for 'Module aware go get', but if you try that example from the doc, it fails with error no matching versions for query "latest"

Or any brief comments on the cases where this would be an issue vs. not an issue?

[bcmills]

This is still on my radar for 1.12, but (depending on the fix) will likely slip to 1.13.

[integrii]

FYI, I am still getting this in go1.12beta1 darwin/amd64 and can only make things work if I go back to the gopath.

build github.com/Comcast/kuberhealthy/cmd/kuberhealthy: cannot load golang.org/x/crypto/ssh/terminal: cannot find module providing package golang.org/x/crypto/ssh/terminal

go clean -modcache gives the same error, strangely enough.

GO111MODULE=off go get -v golang.org/x/crypto/ssh/terminal works, but obviously not for things out side GOPATH.
GO111MODULE=on go get -v golang.org/x/crypto/ssh/terminal does not work with the following error:

go get golang.org/x/crypto/ssh/terminal: no matching versions for query "latest"

[subfuzion]

HACK: For what it's worth, the following succeeds after the first attempt to go get without "...":

go get -u golang.org/x/tools
go get -u golang.org/x/tools/...

I discovered this when struggling to get go generate to work for go-bindata

go get -u github.com/go-bindata/go-bindata
go get -u github.com/go-bindata/go-bindata/...

In my case, the first line is necessary for the following to succeed:

//go:generate go get github.com/go-bindata/go-bindata
//go:generate go get -u github.com/go-bindata/go-bindata/...
//go:generate go-bindata -pkg $GOPACKAGE -o assets.go -prefix assets/ assets/...

Hope this helps anyone else.

EDIT: My bad -- I didn't notice that the solution was already mentioned in this previous comment when I skimmed through this the first time. I was going to delete my comment, but decided that it might still be helpful to anyone landing here and missing the earlier comment like I did.

[srinathh]

This breaks the workflow of installing go from source because installing additional tools doesn't work if GO111MODULE=on has been set. I ran into this when re-installing Go from source and my work around was to turn off the setting first first, install & then turn it back on. While not many folks will run into this, a note should probably be added to the documentation on installing from source noting the issue.

[mholt]

Commenting to confirm that running go get without the /... pattern first, then running go get with the /... pattern works. But I second the earlier comments that this is not in agreement with the documentation.

[thepudds]

@bcmills @jayconrod Any quick thoughts on whether a fix for this might be small enough to be a 1.12 back port candidate?

@mvdan asked a similar question a bit ago in #29363, which I think might be a duplicate of this one.

This issue is fairly awkward given the number of readmes out there that use /... as part of their installation instructions. Of course, it might make more sense to wait until 1.13 based on the nature of a fix, competing priorities, etc.

[thepudds]

The example I had listed above in #27215 (comment) seems to be fixed in tip now that #29363 is fixed.

Is anyone else still seeing an issue here if you try with tip?

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

[jayconrod]

I think this can be closed after CL 174099 and other fixes to go get landed. go get golang.org/x/tools/... should work now.

Sorry I don't think there was anything in here that could be backported to 1.12. The changes to go get semantics were pretty substantial. In general, go get in 1.13 in module mode should have similar semantics to go get in GOPATH mode.

[hexiao04]

so, how to solve this kind of problem?
"no matching versions for query "latest"

[dmitshur]

@hexiao04 This is an old closed issue. If there is a problem, please file a new issue, and reference this one if you think it's relevant. For questions, please see https://golang.org/wiki/Questions.