hckrnws

As someone who recently set up something similar in Emacs with eglot I had to ditch Python-LSP-server.

It was so incredibly slow to respond, even on a M2 Max MBP, that it lowered my productivity by orders of magnitudes (and made Emacs laggy).

Maybe I did something wrong? I don’t know.

What I do know is that I tried pyright instead as a different LSP-server for Python and I haven’t looked back.

It’s a night and day difference. It’s snappy and everything works as expected, with venvs and mypy too.

I agree. I really wanted to like python-lsp-server (aka pylsp), but I felt it's kind of a mess getting everything set up and configured. Loathe as I was to configure a server running in Node to help my editor with Python code, it's far and away the best option I've found so far.

I do hope "ruff server" will do for Python LSPs what ruff did for linting and formatting.

It's not ready yet, but https://pyrefly.org/ might be a good competitor/complement in the future

Looks promising! It doesn't work with my poetry environment, but I like what I see so far. Definitely something to watch.

Hi! I'm on the team behind Pyrefly. Thanks for taking a look and raising the need for poetry support. We added a GitHub issue to track that here: https://github.com/facebook/pyrefly/issues/166

I haven't tried the Ruff server yet, but Jedi Language Server is usably fast, and does a good enough job.

Jedi's very nice for refactoring and auto-completion! I get more value from linting and type checking, though, and Jedi doesn't handle those. Pairing it with something like pyright is a great combination if your editor lets you connect to multiple servers.

last time i looked the people were recommending basedpyright: https://github.com/DetachHead/basedpyright

I've been recommending it whenever Pylance comes up on HN or Lobsters, the docs explain how to set it up on the most popular editors: https://docs.basedpyright.com/dev/installation/ides

Might not be an issue for your typical setup, but I suggest quoting your variable expansions in bash. Otherwise, spaces, etc., will lead to issues.

It would also make sense to use path after it is defined, instead of sometimes using `$1` again.

But I'm confused by `cd`ing into `$path` and then checking paths that are prefixed by `$path`... I assume that is an error, and you won't run it like `script.sh ./work/project` and expect a path like `./work/project/work/project` or `./work/project/project` to exist. Can just `cd "$1"` and be done.

Mildly surprised the .venv/venv check isn't an elif as well.

  #!/usr/bin/env bash
  cd "$1"
  if [ -d ./.venv ]; then
    source ./.venv/bin/activate
  elif [ -d ./venv ]; then
    source ./venv/bin/activate
  fi
  exec pylsp --check-parent-process

Not particularly relevant to the core article, but just a dumb thought re: the LSP/LS annoyance mentioned in the intro.

I think maybe some of it stems from 'ls' the command. If I saw something called py-ls instead of py-lsp, I may think it's a python based ls command. "Name Collision" as it were.

Anyways off to read the rest of the article...

I wrote a language server too, and I also went with "-lsp" naming because it's way more recognizable. "LSP" is kind of a brand. If you look at the list at https://microsoft.github.io/language-server-protocol/impleme... a lot of them are named -lsp.