Maybe use initializationOptions as additional source of settings

[krobelus]

This came up in this issue with the kak-lsp client.
Before the workaround for that issue, kak-lsp sent server configuration via the initialize request (in initializationOptions).
It only sent workspace/didChangeConfiguration when the configuration actually changed.
This caused problems because pylsp ignores initializationOptions. The workaround is to re-send options with workspace/didChangeConfiguration.

I wonder if it's a good idea to use initializationOptions as additional settings source.
I see two possible variants:

1. Always include initializationOptions but let workspace/didChangeConfiguration override its settings
2. As soon as workspace/didChangeConfiguration arrives, forget the initializationOptions

Annoyingly, option 2 would not have fixed the kak-lsp issue, because kak-lsp used to an empty
settings object in workspace/didChangeConfiguration (but that's an issue on our side).

It's probably also fine to leave it; LSP is quite underspecified about how these requests interact. I heard that both are deprecated in favor of workspace/configuration..

[rchl]

workspace/didChangeConfiguration is a notification sent from the client to the server while workspace/configuration is request sent from the server to the client. Different use cases and none is deprecated.

initializationOptions' shape is server-defined and might or might not be used for sending the options if server wishes so but since it can only be sent once (on initialization) it is not the best use case for settings that can change at runtime. It's good for options that need to be known before server initializes though.

It doesn't really make sense for this server to read its settings from initializationOptions unless a given option really needs to be known that early.

It sounds like you are suggesting to add extra code and complicate the project because of particular client's limitation/deficiencies (not supporting workspace/configuration and/or workspace/didChangeConfiguration).

[krobelus]

It doesn't really make sense for this server to read its settings from initializationOptions unless a given option really needs to be known that early.

Makes sense but IMO an LSP client should not need to know whether an option is required early during initialization.
So the only generic solution I see is to send configuration with both requests.
Anyway, the real problem is that LSP is really vague, so clients need to support different interpretations.

[rchl]

I don't think that LSP is vague here. The protocol defines initializationOptions which can have any shape and it's up to the server to define that and it also defines a "Settings" object which is an object unrelated to initializationOptions. Particular server chooses what options it expects from either of those.

And a generic client implementation can never know what settings a particular server expects. It should be always up to the server-specific configuration defined separately from the generic client implementation to define which options to pass where. It's wrong for a generic client implementation to assume that both of those accept the same set of options.

[krobelus]

I don't think that LSP is vague here.

OK, not vague but "requires knowledge of servers to implement rcorrectly".

So there are three different configuration options initializationOptions, workspace/didChangeConfiguration and workspace/configuration.
The most flexible client would allow the user to configure each option independently.
However, that'd be pretty bad UI. Of course, VSCode exposes a single config file and I guess the server-specific extensions take care of forwarding the right options.
We've tried to mimic the structure of that config file. This allowed us to use the same settings object for workspace/didChangeConfiguration and workspace/configuration (modulo the server-specific "section name"), which might pose an issue too.
Anyway, apparently we need another bit of information to control initializationOptions.
Thanks for clarifying.

[rchl]

So there are three different configuration options initializationOptions, workspace/didChangeConfiguration and workspace/configuration.
The most flexible client would allow the user to configure each option independently.

The workspace/didChangeConfiguration and workspace/configuration are supposed to work on the same underlying configuration options so there shouldn't be a way for a client to specify those separately.

[siegel]

At the risk of reopening old wounds :-), it seems typical for language servers to send workspace/configuration to affirmatively request any configuration data from the client, irrespective of whether any was included in initializationOptions. (I'm not here to relitigate the question of whether configuration in initializeOptions is appropriate; I don't think that's a relevant question here.)

At the moment, I've got a customer who can't configure pylsp the way they need to, because it evidently never sends a workspace/configuration request to the client. My code never sends configurationDidChange because there's no need to: configuration is done using external files, and these are read only once. No change, therefore no change notification. (And it feels really weird to send a change notification when there hasn't been a change; as far as I am aware, this requirement is atypical to pylsp.)

So if it's practical to send a workspace/configuration request to the client it seems like that would address what appears to be a recurring reported issue, and would probably improve behavior and compatibiltiy with editors that aren't VS Code or vim. :-)

[ccordoba12]

@siegel, thanks for your feedback. If this requires only sending workspace/configuration and not much else, then I'm ok with it. Just open a PR and I'll review it.

[siegel]

@ccordoba12 Thanks! I appreciate your willingness to adopt a change. I regret that the work is outside of my expertise; I am a consumer of the server, but know nothing about its internals (nor, alas, would I feel comfortable trying to learn the internals in any reasonable amount of time).

But if anyone else feels comfortable making the necessary change, then I am delighted to test it when it gets merged and released.

[ccordoba12]

Ok, I have no problem with that, but since this doesn't directly benefit us (i.e. it's a feature we won't use in Spyder), it'll go to the backlog of things I have to do. So, this could take a long time to be solved.

However, you said:

I've got a customer who can't configure pylsp the way they need to

So, since this is for a paid job, I'd say that if you're willing to make a good donation to our Open Collective, then I'd take a look at it sooner (two or three weeks). If you're interested, please send me an email (it's in my profile) to discuss the details.

[siegel]

So, since this is for a paid job

I'm not getting paid for this. :-) However, the customer has expressed an interest in working on this themselves, so they may be submitting a PR at some point.

[kstrauser]

Hi @ccordoba12! I’m the customer in question. For clarity, my end goal is to use:

• BBEdit
• …with pylsp
• …and python-lsp-ruff
• and a baseline configuration that I can use in all the code I’m working on, even when that code doesn’t have a pyproject.toml.

I’d be more than happy to take a crack at this. After digging through the code, though, I’m not entirely sure where would be the right place to start. My hypothesis (feel free to laugh!) would be that it would look something like:

• pylsp initializes itself
• pylsp sends workspace/configuration to BBEdit
• BBEdit responds with the config I put in it
• Happiness!

Alternatively, BBEdit already supports workspace-specific configuration. That seems like an ideal and broadly useful feature for pylsp.

[siegel]

Alternatively, BBEdit already supports workspace-specific configuration. That seems like an ideal and broadly useful feature for pylsp.

That's a very client-specific feature; I don't know if it makes sense for the server to implement it. But others may know better than I. :-)