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.

Sign up for GitHub

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

Jump to bottom

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

Closed
lcheylus opened this issue Oct 28, 2023 · 12 comments
Closed

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

lcheylus opened this issue Oct 28, 2023 · 12 comments
Assignees
@findleyr
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
gopls/v0.15.0

Comments

@lcheylus
Copy link

gopls version

Build info
----------
golang.org/x/tools/gopls (devel)
    golang.org/x/tools/gopls@(devel)
    github.com/BurntSushi/[email protected] h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=
    github.com/google/[email protected] h1:O2Tfq5qg4qc4AmwVlvv0oLiVAGB7enBSJ2x2DqQFi38=
    github.com/sergi/[email protected] h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/exp/[email protected] h1:2O2DON6y3XMJiQRAS1UWU+54aec2uopH3x7MAiqGW6Y=
    golang.org/x/[email protected] h1:I/DsJXRlw/8l/0c24sM9yb0T4z9liZTduXvdAWYiysY=
    golang.org/x/[email protected] h1:zxkM55ReGkDlKSM+Fu41A+zmbZuaPVbGMzvvdUPznYQ=
    golang.org/x/[email protected] h1:Af8nKPmuFypiUBjVoU9V20FiaFXOcuZI21p0ycVYYGE=
    golang.org/x/[email protected] h1:1baVNneD/IRxmu8JQdBuki78zUqBtZxq8smZXQj0X2Y=
    golang.org/x/[email protected] h1:ablQoSUd0tRdKxZewP80B+BaqeKJuVhuRxj/dkrun3k=
    golang.org/x/[email protected] h1:885/39rn2IDn/hUUfUzxMWAowSMB/K+bc3kaOJfc5bo=
    golang.org/x/[email protected] h1:KUas02EjQK5LTuIx1OylBQdKKZ9jeugs+HiqO5HormU=
    honnef.co/go/[email protected] h1:YGD4H+SuIOOqsyoLOpZDWcieM28W47/zRO7f+9V3nvo=
    mvdan.cc/[email protected] h1:JVf4NN1mIpHogBj7ABpgOyZc65/UUOkKQFkoURsz4MM=
    mvdan.cc/xurls/[email protected] 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
Member

Thanks for reporting this, @lcheylus. With [email protected] 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/[email protected], 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
Member

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
Member

@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 [email protected].

@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 •
edited
Loading

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
Member

([email protected] ended up being a tiny patch release for #63832, so this will be in v0.15.0)

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/555636 mentions this issue: gopls: simplify gopls command configuration

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/555457 mentions this issue: gopls: add a main.version variable to override the version at linktime

gopherbot pushed a commit to golang/tools that referenced this issue Jan 12, 2024
@findleyr
gopls: simplify gopls command configuration
b37fde9 
Clean up configuration options for the gopls command that are no longer
relevant:

1. remove Application.name, since it can always be "gopls"
2. remove Application.wd, since it can always be os.Getwd()
3. remove Application.env, since it can always be os.Environ()
4. remove magic internal@ connection strings

For (1) I don't know why the capabilities test modified
Application.name, but since this is the only place that customized the
name, and it is a test which still passes, it can't be important.

Items (2), (3), and (4) only existed for subverting the existing means
of configuring gopls via either (1) the operating system or (2) the LSP.
For example, if we want to modify gopls's environment, we can do so via
a subprocess or via environment passed into the gopls session during
initialization. No need to have a third and unofficial means of doing
so.

For golang/go#63803

Change-Id: Ib5a478b689f315813bdfff263afd9d037f368d3c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/555636
Reviewed-by: Alan Donovan <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
@lcheylus
Copy link
Author

Build with -ldflags main.version='0.15.0' OK with gopls v0.15.0 sources:

$ gopls version
golang.org/x/tools/gopls v0.15.0

Thanks for this fix.

@gabyhelp gabyhelp mentioned this issue Jun 16, 2024
Closed
@gabyhelp gabyhelp mentioned this issue Sep 26, 2024
Closed
@gabyhelp gabyhelp mentioned this issue Dec 6, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@findleyr findleyr

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
Milestone
gopls/v0.15.0
Development

No branches or pull requests
5 participants
@lcheylus @hyangah @gopherbot @seankhliao @findleyr