Problem
Extensions such as vscode-pylint (see vscode-pylint#476) spawn a Language Server process (e.g. lsp_server.py) for every folder in a multi-root workspace, even when these folders share the same configuration or interpreter. This is the default behavior in VS Code extensions, but leads to redundant processes, duplicated linting (and logs/diagnostics), and unnecessary resource usage in projects with many folders.
Currently, vscode-common-python-lsp provides utilities for settings resolution and server lifecycle, but it still assumes and implements a one-client-per-workspace-folder model and does not provide a mechanism to:
- Start one language server across all folders (when appropriate)
- Avoid redundant or duplicate LSP processes for subfolders
- Allow the user to configure (disable) tool extensions per workspace folder (e.g., simulate a
tool.enable = false setting)
Request
- Add first-class support for more advanced multi-root workspace scenarios:
- Option 1: Support a singleton LanguageClient/Language Server mode across multiple folders with compatible config/interpreter
- Option 2: Provide APIs/utilities or recommended patterns to allow extension authors to implement per-folder enable/disable logic (e.g.,
pylint.enable: false)
- Optionally, add sample code and documentation for how to prevent duplicate processes or respect per-folder settings.
Example motivating issue
See original problem and user request: microsoft/vscode-pylint#476
Notes
- This would benefit all Python tool extensions consuming this library, not just pylint.
- If implemented here, it would encourage consistency and reduce redundant issue reports/upstream maintenance.
Thanks for considering!
Problem
Extensions such as vscode-pylint (see vscode-pylint#476) spawn a Language Server process (e.g.
lsp_server.py) for every folder in a multi-root workspace, even when these folders share the same configuration or interpreter. This is the default behavior in VS Code extensions, but leads to redundant processes, duplicated linting (and logs/diagnostics), and unnecessary resource usage in projects with many folders.Currently, vscode-common-python-lsp provides utilities for settings resolution and server lifecycle, but it still assumes and implements a one-client-per-workspace-folder model and does not provide a mechanism to:
tool.enable = falsesetting)Request
pylint.enable: false)Example motivating issue
See original problem and user request: microsoft/vscode-pylint#476
Notes
Thanks for considering!