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 the expectation on workspace/configuration #41966

Closed
hyangah opened this issue Oct 14, 2020 · 15 comments
Closed

x/tools/gopls: clarify the expectation on workspace/configuration #41966

hyangah opened this issue Oct 14, 2020 · 15 comments

Comments

@hyangah
Copy link
Contributor

@hyangah hyangah commented Oct 14, 2020

For each folder in workspace, gopls currently sends a workspace/configuration request asking for two sections (gopls and gopls-<foldername>). For example, this is the configuration request/response trace when there are two folders (hello and hello2).

[Trace - 23:40:23.343 PM] Received request 'workspace/configuration - (2)'.
Params: {"items":[{"scopeUri":"file:///Users/hakim/hello","section":"gopls"},{"scopeUri":"file:///Users/hakim/hello","section":"gopls-hello"}]}

[Trace - 23:40:23.349 PM] Sending response 'workspace/configuration - (2)' in 5ms.
Result: [{"env":{}},null]

...

[Trace - 23:40:23.467 PM] Received request 'workspace/configuration - (4)'.
Params: {"items":[{"scopeUri":"file:///Users/hakim/hello2","section":"gopls"},{"scopeUri":"file:///Users/hakim/hello2","section":"gopls-hello2"}]}

[Trace - 23:40:23.495 PM] Sending response 'workspace/configuration - (4)' in 28ms.
Result: [null,null]

I was told the gopls-<foldername> section is to allow per-folder configuration. However, given that gopls issues multiple configuration requests for each folder, I am not sure about this.

In case of vscode, it computes the effective configuration for the requested sections in the context of the requested scopeUri (by merging global+workspace+folder configuration) and returns the merged values. Even though this additional section request is not harmful and vscode-go can keep returning null, documenting the purpose and the expected client behavior would be nice.

@myitcv
Copy link
Member

@myitcv myitcv commented Oct 14, 2020

@gopherbot
Copy link

@gopherbot gopherbot commented Oct 19, 2020

Change https://golang.org/cl/263524 mentions this issue: internal/lsp: remove per-workspace configuration

@stamblerre stamblerre modified the milestones: gopls/v0.5.2, gopls/v1.0.0 Oct 20, 2020
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Oct 29, 2020

This has been discussed at length on Slack (starting at https://gophers.slack.com/archives/CRWSN9NCD/p1603374985082900), but let's move the discussion to this issue to make it a little more permanent.

@myitcv said:

The last time I checked there wasn't a way for me to say "this file I'm opening should be considered to be open within workspace folder B, which is where I have set GOOS=js GOARCH=wasm"
Where workspace folders A and B intersect (in terms of directory trees), this is relevant because it's otherwise ambiguous when doing something with a file in that intersection
So whilst the configuration request from server to client is unambiguous, and call from client to server can be ambiguous

I agree that this is an ambiguity of the LSP, but I'm not sure how this is resolved by the gopls-<name> configuration. If you've opened both A and B (say A is foo/bar and B is foo/bar/baz) then gopls would request workspace/configuration for both foo/bar and foo/bar/baz. There is definitely an issue of intent if foo/bar depends on foo/bar/baz with different build tags, and the user jumps to the definition of something in foo/bar/baz--but I don't think the gopls-<name> configuration would address that in any way.

@myitcv
Copy link
Member

@myitcv myitcv commented Oct 29, 2020

I agree that this is an ambiguity of the LSP, but I'm not sure how this is resolved by the gopls-<name> configuration

I don't think @ianthehat (or indeed anyone) claimed it was resolved by this approach, rather that this configuration mechanism (plus the "closest match" logic) was the best approximation given the options available to us via LSP.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Oct 30, 2020

Ok, then I guess it's still not clear to me that this configuration setting is offering anything more than existing per workspace folder configuration requests.

I guess it saves the user the hassle of manually changing the configuration when they switch between build tags, but that feels like something that could be pushed into the level of the client.

@myitcv
Copy link
Member

@myitcv myitcv commented Oct 30, 2020

I guess it saves the user the hassle of manually changing the configuration when they switch between build tags, but that feels like something that could be pushed into the level of the client.

From memory, the idea behind this setup was that it allowed the user to concurrently edit files within a subtree of a module using a different build configuration (GOOS, GOARCH and build tags). The canonical example being the WASM subtree.

Doesn't pushing this to the client mean the user would have to flip backwards and forwards as they flip to/from the subtree, thereby negating the "concurrently" bit?

It's possible I'm not fully understanding the motivation behind making this change.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Nov 2, 2020

By concurrently, do you mean in different sessions or in the same session?
If it's the same session, then it sounds like that's already not possible given the ambiguity of having overlapping workspace folders in the same session.

@myitcv
Copy link
Member

@myitcv myitcv commented Nov 2, 2020

By concurrently, do you mean in different sessions or in the same session?

Same session.

If it's the same session, then it sounds like that's already not possible given the ambiguity of having overlapping workspace folders in the same session.

But that's where I believe @ianthehat established logic to choose the view that best corresponded to the file in question. Because a view on a subdirectory tree of a module is more specific, and hence if a file is contained within that tree then that view is used.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Nov 2, 2020

True. But still, it's possible to configure overlapping directories differently without a gopls-<name> setting.

I would be very surprised if it were possible to work on the same workspace folder with different configurations in one session, and I think that's the case that this gopls-<name> configuration was meant to support.

@stamblerre stamblerre added this to Needs Triage in vscode-go: gopls by default Nov 10, 2020
@stamblerre stamblerre moved this from Needs Triage to Non-critical in vscode-go: gopls by default Nov 10, 2020
@stamblerre stamblerre moved this from Non-critical to Critical in vscode-go: gopls by default Nov 11, 2020
@stamblerre stamblerre moved this from Critical to Non-critical in vscode-go: gopls by default Nov 11, 2020
@stamblerre stamblerre moved this from Non-critical to Critical in vscode-go: gopls by default Nov 11, 2020
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Nov 11, 2020

@myitcv: Based on this discussion, I'm still inclined to remove the configuration, as I'm still not clear on what concrete use case it supports. If you are opposed to the configuration being removed, can you please provide an example of a project in which it would be useful with an explanation of how to use it? Thanks!

@stamblerre stamblerre moved this from Critical to In progress in vscode-go: gopls by default Nov 11, 2020
@myitcv
Copy link
Member

@myitcv myitcv commented Nov 12, 2020

I'll defer to @ianthehat and @bhcleek on that question, because theirs was the original use case behind this (as was the original support in vim-go). As I mentioned elsewhere, we do not (yet) support multiple workspaces folders in govim. However, we would be interested in doing so if we can work out the right UI/UX.

@ianthehat
Copy link

@ianthehat ianthehat commented Nov 12, 2020

As far as I am concerned the entire thing was a GopherCon hack so we could explore and experiment, if the conclusion is that this is the wrong path to take then it should go away (even if it has been a very very long time since we started the experiment). I have certainly never used it, but then I was not the target user either.

@bhcleek
Copy link
Contributor

@bhcleek bhcleek commented Nov 12, 2020

TL;DR: one workspace configuration per workspace is fine for vim-go.

Vim-go does not need two workspaces configurations per workspace, but it does need to be able to configure multiple workspaces.

IIRC correctly, gopls would create a workspaceConfiguration on initialization named gopls and then each workspace was given a name that was prefixed with gopls- when this feature was first created. My understanding at the time was that the workspace created on initialization was getting two workspaceConfigurations, and vim-go handles that fine, but it configures them both the same. I don't recall that subsequent workspaces were getting two configurations each. 🤷

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Nov 12, 2020

Thanks for following up. I think it makes sense to remove the gopls-<name> configuration then, since it's not actually being used by any clients.

@gopherbot
Copy link

@gopherbot gopherbot commented Nov 12, 2020

Change https://golang.org/cl/269597 mentions this issue: internal/lsp: remove gopls-<name> configuration

vscode-go: gopls by default automation moved this from In progress to Done Nov 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants