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

Jump to bottom

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

Open
stamblerre opened this issue Nov 25, 2020 · 2 comments
Open

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

stamblerre opened this issue Nov 25, 2020 · 2 comments
Labels
FeatureRequest gopls NeedsDecision Tools
Milestone
gopls/later

Comments

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Nov 25, 2020

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 label Nov 25, 2020
@gopherbot gopherbot added Tools gopls labels Nov 25, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Nov 25, 2020

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

@stamblerre stamblerre added this to Needs Triage in vscode-go: gopls by default Nov 25, 2020
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 removed this from Needs Triage in vscode-go: gopls by default 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
@stamblerre stamblerre added this to the gopls/unplanned milestone Dec 16, 2020
@stamblerre stamblerre removed this from the gopls/unplanned milestone Dec 18, 2020
@stamblerre stamblerre added this to the gopls/v1.0.0 milestone Dec 18, 2020
@stamblerre stamblerre added this to To Do in gopls on-deck Feb 28, 2021
@gudvinr
Copy link

@gudvinr gudvinr commented Apr 9, 2021 •
edited

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
FeatureRequest gopls NeedsDecision Tools
Projects
No open projects
gopls on-deck
To Do
Milestone
gopls/later
Development

No branches or pull requests
4 participants
@ansaba @gudvinr @stamblerre @gopherbot