-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
Comments
Thanks for reporting this, @lcheylus. With gopls@v0.14.0 we switched from hard-coding the version to using the version reported by We did this to simplify our release process, which we are working on automating. Since we expect that most people install gopls with Do you feel strongly that we should revert this behavior? If so, why? |
see also #50603 |
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 This port is built via Makefile with |
Thanks. Is this consistent with what you have to do for other programs? |
For others Go programs I packaged on OpenBSD, I often use For example, for fzf, I set FreeBSD ports use also the same technique. For example, for |
@lcheylus how about we do the following: we can provide a If that would be helpful, we can do that for gopls@v0.14.2. |
Yes, it would be a perfect solution: create a Thanks if you can implement it in a future version of |
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? |
(gopls@v0.14.2 ended up being a tiny patch release for #63832, so this will be in v0.15.0) |
Change https://go.dev/cl/555636 mentions this issue: |
Change https://go.dev/cl/555457 mentions this issue: |
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 <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Build with $ gopls version
golang.org/x/tools/gopls v0.15.0 Thanks for this fix. |
gopls version
go env
What did you do?
I built
gopls
version 0.14.0 with Go 1.21.3 on OpenBSD/amd64 :tools-gopls-v0.14.0
cd tools-gopls-v0.14.0/gopls
gopls
binary withgo build -v
: OKgopls
internal version is displayed:What did you expect to see?
I except to see internal version 0.14.0 instead of devel as in previous versions :
This behaviour to get version was modified in 0.14.0 release by this commit golang/tools@c28af0a
The text was updated successfully, but these errors were encountered: