Support initializationOptions to configure the server

[tkrabel-db]

What changes are proposed in this pull request?

Fixes #195.

The language server supports passing initializationOptions with the initialize message, but actually doesn't do anything with it. I think this was an oversight. This PR supports overriding configuration settings using the initializationOptions field.

How is this tested?

• Added a unit test
• Manually

[tkrabel-db]

Using this as an example as this is a real world example for when to override confs

[rchl]

Language servers typically don't scope initialization settings to server name because, unlike the workspace settings, those are specific to the server itself and don't have any chance of conflicting with other settings.

[tkrabel-db]

I am happy to address this, but it seems that there is lack of consensus on whether initializationOptions should be used for server configuration.

[ccordoba12]

pylsp is the options namespace used for this server, so I'm fine with using it here.

[krassowski]

Some context:

• as per spec initialization options are different from configuration options; however there is no agreement as to how they are different; there was an attempt to standardize it in microsoft/language-server-protocol@545cd69 but after discussion in lsp#567 it was reverted due to lack of consensus
• this was previously discussed in Maybe use initializationOptions as additional source of settings #195 so it is not an omission - we should follow the discussion in there
• one way that these two could be use used differently, and are used differently by some language server is following microsoft/language-server-protocol@545cd69: initialization options could include pythonVersion: string which is required during initialization but configuration options would have showWarnings: boolean which can be adjusted on runtime

[tkrabel-db]

@krassowski thanks for the context.

I have a clear use case in mind: enabling rope_autoimport without a config file. From the code and #195 I see that workspace/didChangeConfiguration is the supported way to achieve that, and I am happy to go with that approach.

I feel the discussion around initializationOptions is unfortunate. There is no consensus around how initializationOptionsshould be used, but many developers find it very useful to configure the server on initialize. I think so too.

As more and more language servers will run in cloud VMs and not on a local machine, these servers need to be configurable dynamically. workspace/configure is a valid general approach to handle server configuration at runtime, but using that to enable/disable some features is overkill, wasteful and will lead to bad user behaviour.

• It's wasteful because you will end up turning off features that might have been enabled already on initialize, consuming resources unnecessarily (think e.g. rope_autoimport, which needs to index python modules; that problem becomes worse when the language server lives in an ephemeral environment like a cloud VM)
• It will lead to bad user behaviour since the client will already send messages and potentially receive responses from features that the used didn't even want to use in the first place (e.g. getting ruff diagnostics instead of flake8 ones).
• It is overkill because it will require extra logic to make sure the server is responsive while requesting workspace/configuration and while applying it (something that would be a no-brainer with initializeOptions as the server hasn't send a response to that yet, so the client keeps waiting)

[tkrabel-db]

Anyway, I moved my comment to #195, i.e. here

[ccordoba12]

Only one tiny suggestion for you @tkrabel-db.

[tkrabel-db]

@ccordoba12 thanks for supporting this feature! I addressed you comment and also refactored the unit test to use the new test util functions

[ccordoba12]

Looks good to me now, thanks @tkrabel-db!