go get -u golang.org/x/tools/gopls@gopls/v0.3.1
Expected gopls to be installed at the newest tagged version
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.
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 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"
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.
Most helpful comment
You're on Fedora, I presume, which disables
proxy.golang.orgby default, making thegocommand vulnerable to #34092. You can temporarily avoid the bug by settingGOPROXY=proxy.golang.org,direct, running withGOPATH=$(mktemp -d), or clearing your cache withgo clean -modcache. The issue should be fixed in 1.14.