sublimelsp / LSP-ruff

LSP helper for ruff - an extremely fast Python linter, written in Rust.

Home Page:https://packagecontrol.io/packages/LSP-ruff

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Server doesn't start

jwortmann opened this issue · comments

Error from the LSP logs (immediately after initialize request):

LSP-ruff: Traceback (most recent call last):
LSP-ruff:   File "<frozen runpy>", line 198, in _run_module_as_main
LSP-ruff:   File "<frozen runpy>", line 88, in _run_code
LSP-ruff:   File "C:\Users\jwortmann\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Scripts\ruff-lsp.exe\__main__.py", line 7, in <module>
LSP-ruff:   File "C:\Users\jwortmann\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Lib\site-packages\ruff_lsp\__main__.py", line 5, in main
LSP-ruff:     from ruff_lsp import __version__, server
LSP-ruff:   File "C:\Users\jwortmann\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Lib\site-packages\ruff_lsp\server.py", line 52, in <module>
LSP-ruff:     from pygls import protocol, server, uris, workspace
LSP-ruff:   File "C:\Users\jwortmann\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Lib\site-packages\pygls\protocol.py", line 56, in <module>
LSP-ruff:     from lsprotocol.types import (
LSP-ruff: ImportError: cannot import name 'WorkspaceConfigurationParams' from 'lsprotocol.types' (C:\Users\jwortmann\AppData\Local\Sublime Text\Package Storage\LSP-ruff\Lib\site-packages\lsprotocol\types.py)

I've checked the file from the error message and WorkspaceConfigurationParams indeed doesn't exist in that file.

Windows 11

This seems to be an issue with pygls and lspprotocol and it's already worked on: openlawlibrary/pygls#317 (comment)

Hello Ruff Folk 😊 Tom here from Pygls, I just wanted to piggyback off this issue here to see if there's something we can do to improve Pygls.

My intuition is that this error occurred because lsprotocol updated in order to fix a different issue charliermarsh/ruff-vscode#116 (which Ruff folk also found!). And because Pygls doesn't pin to any particular version of lsprotocol then Pygls inherited this new error that this issue is reporting.

So what I'm wondering is what our options are for avoiding these kinds of issues in the future? Firstly, we did take somewhat of a calculated risk in depending on lsprotocol whilst it hasn't hit v1 yet. So maybe we've caused some unnecessary hiccups with that decision, but hopefully that's just short term whilst lsprotocol settles down. So the other thing is version pinning. I think tools like poetry and its poetry.lock can at least offer a way for holding back upstream bugs like this? Unfortunately lsprotocol itself isn't yet using semantic versioning, so we don't have any other option in Pygls itself to soft pin to say, minor versions, eg; ~0.1.

So I don't have a specific question per se, just wondering if anybody has any thoughts around this.

We are using pip to install dependencies which doesn't have a way to generate "lock files" but I found that "pip-tools" can generate pip-compatible requirements.txt files with all used packages listed. So created #9 to add this generated file. The Github's dependabot will notify us about all package updates and we can choose whether we want to update or not.