Can't set ignored error codes

[astoff]

I'm sending the following configuration to pylsp via the didChangeConfiguration notification but I don't get the desired effect of disabling error code D101:

{
  "pylsp": {
    "plugins": {
      "pycodestyle": {
        "enabled": false
      },
      "pyflakes": {
        "enabled": false
      },
      "ruff": {
        "enabled": true,
        "ignore": [
          "D101"
        ]
      }
    }
  }
}

However, if I switch pylsp.ruff.enabled to false, the plugin is disabled, so the editor part of my setup must be working.

[jhossbach]

Please enable debug messages for pylsp and post the log messages here, i.e. by starting pylsp with pylsp -vvv --log-file /tmp/lsp.log

[jhossbach]

Thx for the log @astoff. This is the relevant line:

2023-02-28 11:58:43,096 CET - DEBUG - pylsp_ruff.ruff_lint - Got ruff settings: {'extendSelect': None, 'enabled': True, 'ignore': ['D101'], 'perFileIgnores': None, 'lineLength': None, 'exclude': None, 'executable': 'ruff', 'select': None, 'config': None}
2023-02-28 11:58:43,097 CET - DEBUG - pylsp_ruff.ruff_lint - Found pyproject file: /.../pyproject.toml, skipping pylsp config.

This was intentionally set in order to leave any configuration to be found by ruff itself.
There are two options here:

• You can add D101 to your ignore/extend-ignore list in the pyproject.toml file. If you are not the only one working on this project this would be advantageous in that it is editor-independent. However if you only want it specifically for your editor option two might be relevant:
• We add a config entry called ignore-extended and make it independent of any pyproject.toml file present. I am reluctant to add the latter functionality as this would likely lead to confusing behaviour

[astoff]

Thanks for looking into this. Indeed, I don't want to change the pyproject.toml file, and my intention was to apply some extra settings on top of it.

Let me explain a bit my workflow. The pyproject.toml file has all the nitty-gritty rules checked by CI and that need to be fulfilled before my code is ready to merge. I can also run them locally with make lint when I'm polishing up my work. On the other hand, when I'm actually coding things up, I don't want to get nagged by details; I only want to see the diagnostics that help me write the code.

I'm not sure which confusing behavior you foresee, but it seems very natural and customary to me that server settings > project settings > system settings get merged, with that order of precedence.

[jhossbach]

I had the same issue once. How about we include any extendIgnore and extendSelect options regardless of config files present?

[astoff]

That would work for me, yes. :-)

[jhossbach]

Pushed and tested, please try on your side.

[astoff]

I just tested here and it works fine so far. Thanks!