Overhaul server configuration #679
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The idea is that all configuration will be managed in a centralised location. The `WorkspaceConfiguration` component will be attached to the main language server will be responsible from merging configuration values from a number of sources. - Initialization options - ``workspace/configuration`` requests - Configuration files While this is not implemented yet, this component will also make sure that the configuration values are kept up to date. Eventually features will be able to subscribe to changes in the sections that they are interested in.
Upon receiving the `initialized` notification the server dynamically registers to receive `workspace/didChangeConfiguration` notifications, if the client supports it. The server will also early request the entire `esbonio` configuration section for each workspace root and the global config so that it's ready to serve internal configuration requests from features. This commit also updates the old uses of `server.get_user_config` to use the new `server.configuration.get` API
Rather than have the logging setup be anything "special", it is now just another LanguageFeature allowing it to take advantage of the APIs provided to them.
To align with the changes in how the server asks for configuration values, this updates and simplifies the code that injects the user's configured Python environment into returned configuration.
`lsp-devtools` is too heavy a dependency to bundle for it to be worth it, especially when you consider the proportion of users who are actually going to make use of it. Instead, the extension now assumes that it is available on the user's PATH
Since the language server treats `workspace/configuration` requests as an override for any options set via config file, it's now important to only send the options that the user has actually set. This means most config options in the VSCode extension are now `null` by default.
Options are read from the `tool.esbonio` namespace
For clients that support it, the language server will be able to listen for changes to `pyproject.toml` files and update its configuration accordingly.
- Move to reference section - Add a custom domain to document esbonio - Explain the updated configuration behavior
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This introduces a dedicated component responsible for managing the server's configuration, reacting to changes in configuration and notifying subscribers of any changes.
Configuration can be read from the following sources, in order of descending precedence
workspace/configurationpyproject.tomlfilesWhen supported by the client, the server can detect changes to configuration and respond automatically to (most) changes
Closes #527