go version)?$ go version go version devel +7307e86afd Sun Nov 8 12:19:55 2020 +0000 linux/amd64 $ go list -m golang.org/x/tools golang.org/x/tools v0.0.0-20201102212025-f46e4245211d $ go list -m golang.org/x/tools/gopls golang.org/x/tools/gopls v0.0.0-20201102212025-f46e4245211d
Yes
go env)?go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/myitcv/gostuff/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/.vim/plugged/govim/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-build946386886=/tmp/go-build -gno-record-gcc-switches"
Putting together a Play with Go guide on how to use the new go install $pkg@$version in Go 1.16 with @mvdan (https://play-with-go.dev/installing-go-programs-directly_go116_en/), we had hoped to be able to use gopls as our canonical example of a Go program. However:
$ go install golang.org/x/tools/[email protected]
go install golang.org/x/tools/[email protected]: golang.org/x/tools/[email protected]
The go.mod file for the module providing named packages contains one or
more replace directives. It must not contain directives that would cause
it to be interpreted differently than if it were the main module.
This is as a result of:
https://github.com/golang/tools/blob/ae6603bdc3c4d025cb6c000c3b8dd778b1355266/gopls/go.mod#L14
gopls install successfully.
As above.
The current guidance is that release versions of modules should not include replace directives:
https://go.googlesource.com/proposal/+/refs/changes/77/243077/15/design/40276-go-install.md#why-can_t-directory-directives-be-used
Also referencing https://github.com/golang/go/issues/26640 for context.
@stamblerre
cc @jayconrod
100% agree - gopls is probably the first module most newcomers to Go have to install, so it's unfortunate that it doesn't follow our own best practices and go install [...]@latest does not work.
Thinking outloud, and as an extension to this issue, it would also be unfortunate for @latest to work, but @master to fail, if we simply remove the replace directives from tagged releases. Though I don't think we can make go install [...]@master work today easily, as that would require a feature like https://github.com/golang/go/issues/26640.
Change https://golang.org/cl/272688 mentions this issue: [gopls-release-branch.0.5] gopls: remove replace from release branch
Most helpful comment
Change https://golang.org/cl/272688 mentions this issue:
[gopls-release-branch.0.5] gopls: remove replace from release branch