Skip to content

x/tools/gopls: consider adding opt-in support for symlinks #42833

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
Closed
stamblerre opened this issue Nov 25, 2020 · 3 comments
Closed

x/tools/gopls: consider adding opt-in support for symlinks #42833

stamblerre opened this issue Nov 25, 2020 · 3 comments
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal. FrozenDueToAge gopls Issues related to the Go language server, gopls. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
gopls/v0.11.0

Comments

@stamblerre
Copy link
Contributor

We currently have partial support for symlinks and no test coverage. We believe that some of the timeouts on the openbsd builder may be caused by the latency of evaluating symlinks.

Some options:

  • Remove support for symlinks completely and document this
  • Add opt-in OR opt-out support for symlinks via a configuration
  • Support symlinks by default, but disable support for symlinks in tests

/cc @heschik @findleyr
@stamblerre stamblerre added this to the gopls/vscode-go milestone Nov 25, 2020
@stamblerre stamblerre added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Nov 25, 2020
@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 Nov 25, 2020
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/273190 mentions this issue: internal/lsp: disable support for symlinks pending decision

gopherbot pushed a commit to golang/tools that referenced this issue Dec 1, 2020
@stamblerre
internal/lsp: disable support for symlinks pending decision
1937afe 
We currently have partial, untested support for symlinks. Remove all
support for now until we come up with a decision.

I thought we could re-enable the OpenBSD trybot since we think it was
failing because of the latency of evaluating symlinks, but it seems like
it's still failing.

Updates golang/go#42833

Change-Id: Iece1741def4eaaeffe5fecd10f884c1cce87f449
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273190
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
@stamblerre stamblerre changed the title x/tools/gopls: make decision about symlink support x/tools/gopls: add opt-in support for symlinks Dec 2, 2020
@stamblerre stamblerre removed this from the gopls/vscode-go milestone Dec 2, 2020
@stamblerre stamblerre changed the title x/tools/gopls: add opt-in support for symlinks x/tools/gopls: consider adding opt-in support for symlinks Dec 2, 2020
@gudvinr
Copy link

gudvinr commented Apr 9, 2021 •
edited
Loading

Remove support for symlinks completely and document this

This would painfully impact productivity if your editor has no support for opening multiple modules in single workspace.
I spent a lot of time recently to make it work and it still doesn't work well.

First of all, experimentalWorkspaceModule requires modules to be present inside single workspace root.
That means you must put all linked projects there.
So, let's say you have multiple projects (projectA and projectB) that use library1 and you want to use on-disk version of this library in both.
Your only option is to make a copy in both projectA and projectB. And it is bad. But that could be easily solved with symlinking library1 into both projects.

Yes, you can make gopls.mod and maintain that by hand. But that's not really a comparable option.

This also can be solved by allowing LSP client to provide workspace information (e.g. vscode has multi-root workspaces where every root not required to be in same subdirectory). But I am not aware if that's a thing right now.

@ansaba ansaba added the FeatureRequest Issues asking for a new feature that does not need a proposal. label May 10, 2022
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/454355 mentions this issue: gopls/internal/lsp: avoid I/O in URI comparison operations

@findleyr findleyr modified the milestones: gopls/later, gopls/v0.11.0 Dec 8, 2022
@golang golang locked and limited conversation to collaborators Dec 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FeatureRequest Issues asking for a new feature that does not need a proposal. FrozenDueToAge gopls Issues related to the Go language server, gopls. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
gopls/v0.11.0
Development

No branches or pull requests
5 participants
@ansaba @gudvinr @stamblerre @gopherbot @findleyr