Skip to content
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

x/tools/gopls: Error for version 0.14.0 with "gopls version" command #63803

Open
lcheylus opened this issue Oct 28, 2023 · 9 comments
Open

x/tools/gopls: Error for version 0.14.0 with "gopls version" command #63803

lcheylus opened this issue Oct 28, 2023 · 9 comments
Assignees
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@lcheylus
Copy link

gopls version

Build info
----------
golang.org/x/tools/gopls (devel)
    golang.org/x/tools/gopls@(devel)
    github.com/BurntSushi/toml@v1.2.1 h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=
    github.com/google/go-cmp@v0.5.9 h1:O2Tfq5qg4qc4AmwVlvv0oLiVAGB7enBSJ2x2DqQFi38=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/exp/typeparams@v0.0.0-20221212164502-fae10dda9338 h1:2O2DON6y3XMJiQRAS1UWU+54aec2uopH3x7MAiqGW6Y=
    golang.org/x/mod@v0.13.0 h1:I/DsJXRlw/8l/0c24sM9yb0T4z9liZTduXvdAWYiysY=
    golang.org/x/sync@v0.4.0 h1:zxkM55ReGkDlKSM+Fu41A+zmbZuaPVbGMzvvdUPznYQ=
    golang.org/x/sys@v0.13.0 h1:Af8nKPmuFypiUBjVoU9V20FiaFXOcuZI21p0ycVYYGE=
    golang.org/x/telemetry@v0.0.0-20231011160506-788d5629a052 h1:1baVNneD/IRxmu8JQdBuki78zUqBtZxq8smZXQj0X2Y=
    golang.org/x/text@v0.13.0 h1:ablQoSUd0tRdKxZewP80B+BaqeKJuVhuRxj/dkrun3k=
    golang.org/x/tools@v0.14.1-0.20231024142323-35a647a9c3fc h1:885/39rn2IDn/hUUfUzxMWAowSMB/K+bc3kaOJfc5bo=
    golang.org/x/vuln@v1.0.1 h1:KUas02EjQK5LTuIx1OylBQdKKZ9jeugs+HiqO5HormU=
    honnef.co/go/tools@v0.4.5 h1:YGD4H+SuIOOqsyoLOpZDWcieM28W47/zRO7f+9V3nvo=
    mvdan.cc/gofumpt@v0.4.0 h1:JVf4NN1mIpHogBj7ABpgOyZc65/UUOkKQFkoURsz4MM=
    mvdan.cc/xurls/v2@v2.4.0 h1:tzxjVAj+wSBmDcF6zBB7/myTy3gX9xvi8Tyr28AuQgc=
go: go1.21.3

go env

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/fox/.cache/go-build'
GOENV='/home/fox/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='openbsd'
GOINSECURE=''
GOMODCACHE='/home/fox/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='openbsd'
GOPATH='/home/fox/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/openbsd_amd64'
GOVCS=''
GOVERSION='go1.21.3'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/home/fox/tmp/tools-gopls-v0.14.0/gopls/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1185168954=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I built gopls version 0.14.0 with Go 1.21.3 on OpenBSD/amd64 :

gopls internal version is displayed:

$ ./gopls version
golang.org/x/tools/gopls (devel)
    golang.org/x/tools/gopls@(devel)

What did you expect to see?

I except to see internal version 0.14.0 instead of devel as in previous versions :

$ ./gopls version
golang.org/x/tools/gopls v0.14.0
    golang.org/x/tools/gopls@(devel)

This behaviour to get version was modified in 0.14.0 release by this commit golang/tools@c28af0a

@lcheylus lcheylus added gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository. labels Oct 28, 2023
@gopherbot gopherbot added this to the Unreleased milestone Oct 28, 2023
@findleyr
Copy link
Contributor

Thanks for reporting this, @lcheylus. With gopls@v0.14.0 we switched from hard-coding the version to using the version reported by runtime/debug.ReadBuildInfo. So if you install gopls using go install golang.org/x/tools/gopls@v0.14.0, you will get the correct version.

We did this to simplify our release process, which we are working on automating. Since we expect that most people install gopls with go install, I did not think this would make a significant difference.

Do you feel strongly that we should revert this behavior? If so, why?
(FWIW, more detailed VCS information is available via go version -m $(which gopls))

@seankhliao
Copy link
Member

see also #50603

@lcheylus
Copy link
Author

Thanks for your explanations. I don't want that your revert this behavior to define gopls version.

I am the maintainer of the OpenBSD port for gopls (named devel/gopls in our tree), see https://github.com/openbsd/ports/tree/master/devel/gopls

This port is built via Makefile with go build.... To fix the internal version for v0.14.0, I need to patch internal/lsp/debug/info.go file => redefine Version function.

@findleyr
Copy link
Contributor

Thanks. Is this consistent with what you have to do for other programs?

@lcheylus
Copy link
Author

For others Go programs I packaged on OpenBSD, I often use -ldflags -X in my Makefile to set version => patching directly string for version in code.

For example, for fzf, I set version string in main.go with -ldflags -X main.version=${VERSION} => see https://github.com/openbsd/ports/blob/master/sysutils/fzf/Makefile

FreeBSD ports use also the same technique. For example, for fzf port, see this Makefile https://github.com/freebsd/freebsd-ports/blob/main/textproc/fzf/Makefile

@findleyr
Copy link
Contributor

@lcheylus how about we do the following: we can provide a main.version variable to override the version. If this is set using -ldflags, we'll report that version from gopls.version. Furthermore, we can indicate in e.g. LSP logs and gopls -v version that this is a user-provided version, which will aide in our investigation of any user reported issues (as we will know that the code may not be exactly the same as the released version).

If that would be helpful, we can do that for gopls@v0.14.2.

@findleyr findleyr modified the milestones: Unreleased, gopls/v0.14.2 Oct 31, 2023
@lcheylus
Copy link
Author

lcheylus commented Nov 1, 2023

Yes, it would be a perfect solution: create a main.version variable that we could override via -ldflags to report it via gopls version.

Thanks if you can implement it in a future version of gopls :)

@findleyr findleyr self-assigned this Nov 1, 2023
@hyangah
Copy link
Contributor

hyangah commented Nov 2, 2023

Out of curiosity - based on the build info, it looks like all dependencies including golang.org/x/tools are acquired from module cache. Why can't the main module downloaded from the module cache like other dependencies? Is it because openbsd port need to apply some patches/modification to the main module?

@findleyr findleyr modified the milestones: gopls/v0.14.2, gopls/v0.15.0 Nov 14, 2023
@findleyr
Copy link
Contributor

(gopls@v0.14.2 ended up being a tiny patch release for #63832, so this will be in v0.15.0)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

5 participants