Go: x/tools/gopls: Cannot install 0.3.1 with go get

Created on 8 Feb 2020  Â·  13Comments  Â·  Source: golang/go

What did you do?

go get -u golang.org/x/tools/gopls@gopls/v0.3.1

What did you expect to see?

Expected gopls to be installed at the newest tagged version

What did you see instead?

go get: golang.org/x/tools/[email protected] requires
        golang.org/x/[email protected]: invalid version: unknown revision 34c67990bfe7

Seeing this is odd since that revision does seem to exist as the commit just before the tag

Cloning the repo and checking out the tag and building worked fine.

Build info

golang.org/x/tools/gopls v0.3.1
    golang.org/x/tools/gopls@(devel)
    github.com/BurntSushi/[email protected] h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/sergi/[email protected] h1:Kpca3qRNrduNnOQeazBd0ysaKrUJiIuISHxogkT9RPQ=
    golang.org/x/[email protected] h1:WG0RUwxtNT4qqaXX3DPA8zHFNm/D9xaBpxzHt1WcA/E=
    golang.org/x/[email protected] h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU=
    golang.org/x/[email protected] => ../
    golang.org/x/[email protected] h1:/atklqdjdhuosWIl6AIbOeHJjicWYPqR9bpxqxYG2pA=
    honnef.co/go/[email protected] h1:3JgtbtFHMiCmsznwGVTUWbgGov+pVqnlf1dEJTNAXeM=
    mvdan.cc/xurls/[email protected] h1:KaMb5GLhlcSX+e+qhbRJODnUUBvlw01jt4yrjFIHAuA=

Go info

go version go1.13.7 linux/amd64

GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/paul/dev/go/bin"
GOCACHE="/home/paul/.cache/go-build"
GOENV="/home/paul/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY="bitbucket.org/getcoinshub/*"
GONOSUMDB="bitbucket.org/getcoinshub/*"
GOOS="linux"
GOPATH="/home/paul/dev/go"
GOPRIVATE="bitbucket.org/getcoinshub/*"
GOPROXY="direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/paul/dev/golang-tools/gopls/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build329549544=/tmp/go-build -gno-record-gcc-switches"
Tools WaitingForInfo gopls

Most helpful comment

You're on Fedora, I presume, which disables proxy.golang.org by default, making the go command vulnerable to #34092. You can temporarily avoid the bug by setting GOPROXY=proxy.golang.org,direct, running with GOPATH=$(mktemp -d), or clearing your cache with go clean -modcache. The issue should be fixed in 1.14.

All 13 comments

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

You're on Fedora, I presume, which disables proxy.golang.org by default, making the go command vulnerable to #34092. You can temporarily avoid the bug by setting GOPROXY=proxy.golang.org,direct, running with GOPATH=$(mktemp -d), or clearing your cache with go clean -modcache. The issue should be fixed in 1.14.

If your goal is to install gopls at the newest tagged version, then instead of:

go get -u golang.org/x/tools/gopls@gopls/v0.3.1

You should run:

go get golang.org/x/tools/[email protected]

Notably, don't include the -u flag. You can also drop the "gopls/" prefix before the version (both work, but it's shorter not to include it).

See canonical gopls installation instructions here.

If you got the command you ran from some documentation, please let us know where it was so we can update it.

Ah, yes, I do have the goproxy disabled by default as I work with a lot of modules still being pulled in via git+ssh

On Feb 8, 2020, at 2:56 PM, Dmitri Shuralyov notifications@github.com wrote:


If your goal is to install gopls at the newest tagged version, then instead of:

go get -u golang.org/x/tools/gopls@gopls/v0.3.1

You should run:

go get golang.org/x/tools/[email protected]

Notably, don't include the -u flag. You can also drop the "gopls/" prefix before the version (both work, but it's shorter not to include it).

See canonical gopls installation instructions here.

If you got the command you ran from some documentation, please let us know where it was so we can update it.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I think the real issue here was the use of the -u flag, as @dmitshur said.
@paulbdavis: Does go get golang.org/x/tools/[email protected] work?

@stamblerre I tried both and they both failed with the same error

Did any of @heschik's suggestions above resolve the issue (https://github.com/golang/go/issues/37140#issuecomment-583776533)?

Closing this issue due to lack of activity. @paulbdavis: If you're still having this problem, please reopen.

Sorry for the inactivity, got busy and my github notifications fell behind.

Anyway, I had this issue again trying to update to v0.3.3-pre1 and I resolved it by prefixing the command with GOPROXY= since I have it set to direct in my env since I work with a lot of private modules still using the .gitconfig hack (I know...)

I'm guessing since this is not the default behavior this issue is not worth actually reopening?

@paulbdavis It would be helpful if you’re able to share the exact command you ran, the exact output your got, and relevant parts of your .gitconfig file.

There may be a problem in the go command that needs to be fixed, but we can’t tell without more information.

I also think you should be able to use private modules without having to resort to hacks, so if that’s not the case, it’s worth opening a separate issue about that and explain why it’s needed. See the second paragraph of https://golang.org/doc/go1.14#introduction.

Thanks.

Sorry, I'm confused. To me this is very clearly a duplicate of #34092. Possibly that fix should be/have been backported to 1.13, but other than that, what is there still to diagnose here?

The latest message just said "had this issue again". If it is exactly the same issue as in the original report, then there's nothing new to diagnose, but I couldn't be sure because there wasn't enough information to confirm that.

@dmitshur The issue was essentially the same, just the specific psuedo versions were for whatever was in the go.mod at the time. I'll try to remember to get a full output tomorrow.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

longzhizhi picture longzhizhi  Â·  3Comments

Miserlou picture Miserlou  Â·  3Comments

ashb picture ashb  Â·  3Comments

OneOfOne picture OneOfOne  Â·  3Comments

bradfitz picture bradfitz  Â·  3Comments