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: clarify supported operating systems #59981

Open
findleyr opened this issue May 4, 2023 · 12 comments
Open

x/tools/gopls: clarify supported operating systems #59981

findleyr opened this issue May 4, 2023 · 12 comments
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

@findleyr
Copy link
Contributor

findleyr commented May 4, 2023

We have experienced a fair amount of friction with gopls tests on e.g. plan9, android, illumos, and solaris. While test failures on these operating systems occasionally turn up real gopls bugs, in my experience failures are more often due to builder problems, resource constraints, and/or bugs in the toolchain. Given that (I assume) few if any of our users are on some of these operating systems, it is almost certain that our resources devoted to these builders results in a net loss for our users.

Unlike other projects on the Go team, gopls is designed for a relatively narrow use-case: development environments. We should not expend resources on ports that are unlikely to serve this use-case for a large number of users. However, we do not specify supported operating systems in our README.

We should specify precisely which operating systems we aim to support, and disable builders for others. At the very least, we will support linux, windows, darwin, and other BSD-like operating systems. I am open to others, but do not want to commit to support if there is no demand.

CC @bcmills @adonovan

@findleyr findleyr added this to the gopls/v0.13.0 milestone May 4, 2023
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels May 4, 2023
gopherbot pushed a commit to golang/tools that referenced this issue May 4, 2023
Skip due to golang/go#58748. We do not have resources to investigate
this failure.

Updates golang/go#59981
Fixes golang/go#58748

Change-Id: I5d695fbeab0b29cedf481ca6b2311bd8c399c4a5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/492495
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/492495 mentions this issue: gopls/internal/lsp/filecache: skip TestConcurrency on plan9 builder

@bcmills
Copy link
Contributor

bcmills commented May 4, 2023

I agree that we do not need to explicitly support android, although after https://go.dev/cl/488655 I suspect that the two Android-specific skips in gopls might no longer be necessary.

(The only other recent changes that have been needed for Android are also needed to support go test on the gopls module when run as a dependency of another module, which I think we should aim to support, provided that that module also requires an appropriate version of x/tools.)

@bcmills
Copy link
Contributor

bcmills commented May 4, 2023

The problems on illumos and solaris seem to be due to builder and/or kernel issues. Those have been reported to the port maintainers (as #59379 and #58782 respectively), so per our porting policy I think we can safely ignore gopls failures on those builders until those issues are addressed.

Beyond the builder-specific issues, most of the API workarounds needed for solaris also apply to aix, our other SVR4-based platform.

@bcmills
Copy link
Contributor

bcmills commented May 4, 2023

As for Plan 9, well, I'm not sure. 😅 The plan9-arm builder, at least, seems to do ok with the gopls tests most of the time.

We occasionally need to add test skips for lack of symlink support, but in theory we also need those for certain versions and/or configurations of Windows, and those skip checks can call general testenv functions that are not specific to Plan 9.

Beyond that we have only two plan9-specific workarounds in place:

To be honest, though, I'm not entirely sure why we don't need an analogous retry loop on Windows. 😅

@bcmills
Copy link
Contributor

bcmills commented May 4, 2023

We should specify precisely which operating systems we aim to support, and disable builders for others.

That may be tricky. Do we currently have a mechanism to skip only a specific submodule within a repo?
I hesitate to drop all of x/tools on a given platform just because gopls doesn't support it.

@findleyr
Copy link
Contributor Author

findleyr commented May 4, 2023

@bcmills I think there's a trap in thinking "well, things seem to be working OK now, so why turn them off". Considerable resources (including a lot of your time specifically!) has been spent tracking down these flakes and reporting bugs upstream. While it is greatly appreciated, we have limited resources and the assertion of this issue is that we would be better off focusing those resources on higher priority environments.

That may be tricky. Do we currently have a mechanism to skip only a specific submodule within a repo?
I hesitate to drop all of x/tools on a given platform just because gopls doesn't support it.

I would definitely not turn off all of x/tools. I think we could probably make a coordinator change to skip just x/tools/gopls.

@findleyr
Copy link
Contributor Author

findleyr commented May 4, 2023

I think there's a trap in thinking "well, things seem to be working OK now, so why turn them off". Considerable resources (including a lot of your time specifically!) has been spent tracking down these flakes and reporting bugs upstream. While it is greatly appreciated, we have limited resources and the assertion of this issue is that we would be better off focusing those resources on higher priority environments.

Some clarification after re-reading: I don't think that's what you're saying, but we've made this mistake in the past. Also: your efforts thus far have been in service of the important goal of test hygiene and engineering standards. This issue is about committing to that same goal.

@bcmills
Copy link
Contributor

bcmills commented May 5, 2023

I think mostly what I'm saying is: given that we probably do want to keep testing the rest of x/tools on most platforms, and given the “curb cut” effects of many of the fixes (for example: fixing the tests on Android also fixes them when run from the module cache; fixing symlink issues on plan9 also fixes them in certain Windows configurations), the engineering cost of skipping gopls tests on the less-supported builders might turn out to be higher than the cost of not skipping them.

But I agree that we should be mindful of the costs in both directions.

@bsiegert
Copy link
Contributor

bsiegert commented Jun 5, 2023

Please don't drop support for the BSDs (FreeBSD, NetBSD, OpenBSD).

@findleyr
Copy link
Contributor Author

findleyr commented Jun 5, 2023

@bsiegert we can do that, but can you explain a bit more? e.g. do you think this affects a large number of users? Is it strategically important to support these GOOS?

@PaluMacil
Copy link

@bsiegert we can do that, but can you explain a bit more? e.g. do you think this affects a large number of users? Is it strategically important to support these GOOS?

I don't use a BSD, but I know that these are platforms commonly used as everyday desktops besides just servers. While I do not expect someone to sit down and write software on Android, and I have never met someone with a need for Solaris, plan9, etc, I would expect that a lot of BSD users are writing software while sitting at a BSD desktop.

@findleyr
Copy link
Contributor Author

@PaluMacil thanks. Yes, I think there are probably some users on BSD, whereas I expect ~zero users on Android or Plan9. Also, generally speaking, BSDs have been less of a problem for us than others.

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