2023-10-11
The wisdom of being selective about python-lsp-server plugins
As far as I know, the most common Python server for the Language Server Protocol is still python-lsp-server (pylsp), although there are now some alternatives (see eg the Emacs lsp-mode page on this for all languages). Pylsp can use a number of plugins (what it calls 'providers') that provide additional checks, warnings, and so on; some are integrated into the pip installation process if you ask for them, and some of them require injecting third party packages. One of these integrated ones is support for pycodestyle.
Although I may have started out not including pycodestyle in my pylsp setup, at some point I started adding it; perhaps I thought it wouldn't do any harm and didn't seem to produce obnoxious warnings. Then I tried another Emacs LSP implementation and discovered that I actually hated pycodestyle's complaints about styles. The reason I hadn't noticed before is that lsp-mode appears to ask pylsp to disable it (the diagnostics you get from a LSP server depend both on your editor's setup and your LSP server).
Although it would be nice if the LSP support in all editors made it straightforward to have a LSP server disable things, the larger lesson for me is that I should stop hitting myself in the face. If I don't want pycodestyle's copious picky complaints about how exactly I format my Python code, I shouldn't include it in my pylsp setup in the first place. The corollary to this is that before I include a linter or a checker in my pylsp setup, it might be a wise idea to try it out separately to see if I like it (before or after customization, as might be necessary for something like ruff). Testing a checker or linter as a standalone thing doesn't guarantee I'll get exactly the same results in pylsp (or any other LSP server), but it's at least something.
(Thus, I think you shouldn't install 'python-lsp-server[all]', because you may be getting a number of surprises. Even if you like what you get now, if you reinstall this later, pylsp may have changed its idea of what 'all' should include in the mean time.)
This also suggests that I should be minimal in my pylsp configuration, just in case. Since I'm going to see the LSP warnings all of the time, more or less, I should stick to things that provide information I almost always want. I can always run additional checkers by hand or by semi-automating them in my editor or even a Makefile.
(I continue to think that setting up Python LSP support in GNU Emacs is reasonably worth it. In Emacs 29.1 you don't even need any third party packages, since 29.1 includes Eglot.)
PS: It's nice to see that Python has picked up a surprising number of linters and checkers while I wasn't looking. A part of me is still way back in the Python 2 era where my option was basically pychecker. And pipx makes it easy to try them out.