As I said several times before, this is not something we can help users with here. It depends on your editor or IDE, i.e. Neovim, Emacs, Sublime, Jupyterlab-LSP, etc.

Most of them allow to set options in json format, so they are sent to the server when it starts. But how to do that, where to put those options and in what format is editor/IDE specific. And most of us here don't use any of the options I mentioned above, so we have no clue about all that.

So the appropriate place to ask for help is in your editor/IDE issue tracker or forum.

Thecurrent docs say:

configuration is loaded from zero or more configuration sources. Currently implemented are:

• pycodestyle: discovered in ~/.config/pycodestyle, setup.cfg, tox.ini and pycodestyle.cfg.
• flake8: discovered in ~/.config/flake8, setup.cfg, tox.ini and flake8.cfg

The default configuration source is pycodestyle. Change the pylsp.configurationSources setting to ['flake8'] in order to respect flake8 configuration instead.

Overall configuration is computed first from user configuration (in home directory), overridden by configuration passed in by the language client, and then overridden by configuration discovered in the workspace.

To enable pydocstyle for linting docstrings add the following setting in your LSP configuration: "pylsp.plugins.pydocstyle.enabled": true

This sounds like 3 config sources:

1. user config
2. "configuration passed in by the language client" i.e. sent from editor
3. configuration discovered in the workspace

You are talking about number 2 here I think. I'm asking about 1 and 3. Doesn't this text mean that you can put something in the workspace to affect configuration - a e.g. asetup.cfg file in a folder? If not, what does it mean?

I'm asking about 1 and 3

Nop, you're asking about 2 as well because neither pycodestyle, flake8 nor any other plugin can be enabled/disabled from user config files.

And this applies to issue#162 too.

Doesn't this text mean that you can put something in the workspace to affect configuration - a e.g. a setup.cfg file in a folder?

Sure, if the plugin is enabled. After that, you can configure it as you would in a regular project.

@ccordoba12 Are you able to point toany examples of adjusting the configuration in a real-project?

I appreciate that all editors do it differently, but the language server protocol a constant, and so we should be able to extrapolate.

At the moment I (and it looks like others) am struggling to get any ofthe 3rd Party Plugins (under the python-lsp org) listed in the README to register...

Sure, if the plugin is enabled.

I'm guessing that's my issue, but I can't get it working, and I can't find a single example to start working from.

Thanks! 🎁

Thanks so much for your reply@ccordoba12 I think I'm getting there, but I'm still quite confused.

If I understand rightly (which I'm not at all confident of), I would rewrite the Configuration section like this:

Configuration

Like all language servers, configuration can be passed from the client (i.e. the editor/IDE). The details of how this is done depend on the editor or plugin that you are using to communicate with python-lsp-server. The configuration options available are documented in CONFIGURATION.md

python-lsp-server depends on other tools, like flake8 and pycodestyle. These tools can be configured via settings passed from the client (first paragraph above), or alternatively other configuration sources. The following sources are available:

• pycodestyle: discovered in~/.config/pycodestyle,setup.cfg,tox.ini andpycodestyle.cfg.
• flake8: discovered in~/.config/flake8,setup.cfg,tox.ini andflake8.cfg

The default configuration source is pycodestyle. Change thepylsp.configurationSources setting (in the value passed in from your client) to['flake8'] in order to respect flake8 configuration instead.

The configuration options available in these config files (setup.cfg etc) are documented in the relevant tools:

• flake8 configuration
• pycodestyle configuration

Overall configuration is computed first from user configuration (in home directory), overridden by configuration passed in by the language client, and then overridden by configuration discovered in the workspace.

As an example, to change the list of errors that pycodestyle will ignore, assuming you are using thepycodestyle configuration source (the default), you can:

1. Add the following to your ~/.config/pycodestyle:

[pycodestyle]
ignore = E226,E302,E41

2. Set thepylsp.plugins.pycodestyle.ignore config value from your editor
3. Same as 1, but added tosetup.cfg file in the root of the project.

This is an attempt to make sense of this, I'm still quite fuzzy on some details, perhaps it's an improvement?

Are you able to point to any examples of adjusting the configuration in a real-project?

Seethis comment for JupyterLab-LSP, although I think theserverSettings key is specific to that project.

This is an attempt to make sense of this, I'm still quite fuzzy on some details, perhaps it's an improvement?

Yes, it is! Thanks for your suggestions@spookylukey!

Could you submit a pull request with them? Thanks!

Hello,

Thanks for opening this issue on this subject, I have been facing the same issue about configuring the language server. In my case, I'm using the client (monaco-languageclient). I understand that the problem might be on the client-side, but looking into the websocket event, I can't find the workspace/didChangeConfiguration being called or even set by default in the capabilities of the server (I tried to manually do that but it's not working either). Client capabilities are set correctly too, with thedidChangeConfiguration dynamicRegistration set to true.

So my question is the following, is the responsibility of the language server to ask for the configuration to the client, or is it the opposite, the client is in charge of sending it during the initialization?
In my case using monaco-languageclient, the didChangeConfiguration functions are never called. I guess I will open an issue on the lib to ask about it.

Another question to make it clearer for the documentation what should be the format of the configuration JSON (client side)?

{    "pylsp": {        "configurationSources": ["flake8"],        "plugins": {            "flake8": {                "enabled": true,                "exclude": [],                "hangClosing": false,                "ignore": ["F401", "E133", "E203", "W503"],                "maxLineLength": 10,                "indentSize": 245,                "perFileIgnores": [],                "select": []            }        }    }}

Or

{    "pylsp.configurationSources": ["flake8"],    "pylsp.plugins.flake8.enabled": true,    "pylsp.plugins.flake8.exclude": [],    "pylsp.plugins.flake8.hangClosing": false,    "pylsp.plugins.flake8.ignore": ["F401", "E133", "E203", "W503"],    "pylsp.plugins.flake8.maxLineLength": 10,    "pylsp.plugins.flake8.indentSize": 245,    "pylsp.plugins.flake8.perFileIgnores": [],    "pylsp.plugins.flake8.select": []}

I'm going to move this to our newly opened Discussions because it's not really a bug but a petition for help.

I'll post further comments there.

I can't find the workspace/didChangeConfiguration being called or even set by default in the capabilities of the server

That request needs to be sent from the client to the server. Our response is handled here:

So my question is the following, is the responsibility of the language server to ask for the configuration to the client

No

or is it the opposite, the client is in charge of sending it during the initialization?

This is the case. The client needs to send that request to the server.

In Spyder that's the second request we send after we receive a response for theinitialize one. In other words, as soon as we detect that the server is up and running, and responded to ourinitialize request, then we send aworkspace/didChangeConfiguration with the necessary parameters to configure it.

Another question to make it clearer for the documentation what should be the format of the configuration JSON (client side)?

I think your first option is the right one, but I'm not really sure. Please experiment with that and let us know which one works for you.

I was trying to configure withhttps://github.com/superlou/lapce-python's plugin.toml

[configuration.options]# Options passed to the LSP server"pylsp.plugins.autopep8.enabled" = false"pylsp.plugins.yapf.enabled" = false"pylsp.plugins.mccabe.enabled" = false

These are included as part of the initialization'initializationOptions': {'pylsp.plugins.autopep8.enabled': False, 'pylsp.plugins.mccabe.enabled': False, 'pylsp.plugins.yapf.enabled': False}, ... but don't seem to have an effect.

An example for Emacs+Eglot.