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: go get golang/x/tools/...: no matching versions for query "latest" #27215

Open
wsc1 opened this Issue Aug 25, 2018 · 13 comments

Comments

Projects
None yet
10 participants
@wsc1

wsc1 commented Aug 25, 2018

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

This comment has been minimized.

Member

bradfitz commented Aug 25, 2018

Do you have GO111MODULE set to "on" ?

@bradfitz bradfitz changed the title from Go1.11 go get golang/x/tools/... to cmd/go: Go1.11 go get golang/x/tools/... no matching versions for query "latest" Aug 25, 2018

@wsc1

This comment has been minimized.

wsc1 commented Aug 25, 2018

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

This comment has been minimized.

rkuska commented Aug 28, 2018

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

This comment has been minimized.

ivanalejandro0 commented Aug 28, 2018

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

This comment has been minimized.

Member

bcmills commented Aug 28, 2018

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

This comment has been minimized.

Member

bcmills commented Aug 28, 2018

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

@ivanalejandro0

This comment has been minimized.

ivanalejandro0 commented Aug 28, 2018

@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.

@FiloSottile FiloSottile added this to the Go1.12 milestone Aug 30, 2018

@FiloSottile FiloSottile changed the title from cmd/go: Go1.11 go get golang/x/tools/... no matching versions for query "latest" to cmd/go: go get golang/x/tools/...: no matching versions for query "latest" Aug 30, 2018

@mastertinner

This comment has been minimized.

mastertinner commented Sep 10, 2018

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

@thepudds

This comment has been minimized.

thepudds commented Oct 7, 2018

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/....

@bigblind

This comment has been minimized.

bigblind commented Oct 26, 2018

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

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

This comment has been minimized.

thepudds commented Oct 26, 2018

@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

This comment has been minimized.

thepudds commented Dec 7, 2018

@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 bcmills unassigned rsc Dec 7, 2018

@bcmills

This comment has been minimized.

Member

bcmills commented Dec 7, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment