LSP_SERVER.workspace is None when initializationOptions are set

[rassie]

This is a weird one, it's more a cry for help than a definitive issue in ruff-lsp. Might be connected to #42, but that's a conjecture at best.

So I'm trying to get my LSP configuration to do what it's supposed to do (Emacs 28.2 + lsp-mode). There seems to be a problem with initializationOptions, so I try both with and without them:

Trial 1: without initializationOptions. Initialization message seems to be alright:

{
  "processId": null,
  "rootPath": "/home/user/project",
  "clientInfo": {
      ...
  },
  "rootUri": "file:///home/user/project",
  "capabilities": {
      ...
  },
  "initializationOptions": null,
  "workDoneToken": "1"
}

The language server starts normally and successfully tries to call ruff on file change (but fails in my case, since it's trying to call /usr/bin/ruff, which is not installed).

Trial 2: with initializationOptions to set both Python binary and ruff binary. Initialization message only differs in those parameters (I sincerely hope the format of interpreter and path is correct):

{
  "processId": null,
  "rootPath": "/home/user/project",
  "clientInfo": {
      ...
  },
  "rootUri": "file:///home/user/project",
  "capabilities": {
      ...
  },
  "initializationOptions": {
    "interpreter": [
      "~/project/.venv/bin/python3"
    ],
    "path": [
      "~/project/.venv/bin/ruff"
    ],
    "logLevel": "debug"
  },
  "workDoneToken": "1"
}

In this case, the language server starts, but fails to call ruff with the following error message:

Failed to handle notification "textDocument/didSave": DidSaveTextDocumentParams(text_document=TextDocumentIdentifier(uri='file:///home/user/project/module/file.py'), text='[snip]')
Traceback (most recent call last):
  File "/home/user/.local/lib/python3.8/site-packages/pygls/protocol.py", line 316, in _handle_notification
    self._execute_notification(handler, params)
  File "/home/user/.local/lib/python3.8/site-packages/pygls/protocol.py", line 228, in _execute_notification
    handler(*params)
  File "/home/user/.local/lib/python3.8/site-packages/ruff_lsp/server.py", line 90, in did_save
    document = LSP_SERVER.workspace.get_document(params.text_document.uri)
AttributeError: 'NoneType' object has no attribute 'get_document'

I'm massively confused at to why this happens. The source code for pygls tells me that setting up a workspace can only fail if root_path/rootPath is not set, but it's set in both cases and should have failed in trial 1 if it fails in trial 2. There is also a peculiar case of pygls somehow transparently converting snake-case to camel-case and vice-versa, but I have to assume it's working somehow.

I honestly don't see a fault in ruff-lsp's handling, but something is happening between ruff-lsp and pygls, which is possibly triggered by my configuration. I just can't see where the problem is happening and what it is.

[charliermarsh]

Can you make sure that the options under initializationOptions are nested one level further, under settings?

E.g., in Sublime, it's like:

{
  "clients": {
    "ruff-lsp": {
      "command": ["ruff-lsp"],
      "enabled": true,
      "selector": "source.python",
      "initializationOptions": {
        "settings": {
          "path": [...]
        }
      }
    }
  }
}

[charliermarsh]

(As-is, you might be overriding stuff on initializationOptions by flattening the settings at that level.)

[charliermarsh]

(It's possible that ~ doesn't work in the interpreter path too, but I have to test that (and can support it if it not).)

[rassie]

Can you make sure that the options under initializationOptions are nested one level further, under settings?

Will try this first thing tomorrow, looks like this might be it. Thanks and I'll keep you posted.

[charliermarsh]

We def didn't support path expansion, but I just fixed it in #44.

[rassie]

Just tried it with ruff-lsp 0.0.11. initializationOptions now look like this:

  "initializationOptions": {
    "settings": {
      "interpreter": [
        "~/project/.venv/bin/python3"
      ],
      "path": [
        "~/project/.venv/bin/ruff"
      ],
      "logLevel": "debug"
    }
  },

Unfortunately, I'm still getting the same problem, a workspace which is None. I also tried explicitely setting workspace and expanding ~ to no avail. Will try to look further myself, but this is the current state of affairs.

[rassie]

A bit more digging. Apparently, my LSP configuration is broken -- turns out, lsp-mode never receives a response to initialize, and thus never sends initialized, which explains why sending any message results in uninitialized workspace. I think there is no bug or issue with ruff-lsp here, I'll have to find out how to write a proper lsp-mode configuration. Thanks for the help!

[charliermarsh]

I wish I could help, but I'm not very familiar with Emacs. If you get it working, I'd love to add instructions to the docs (#19).

[rassie]

That's more or less what I aim for, yes. Ideally I'd get the client PRed to lsp-mode, gotta get it running first.

[rassie]

@charliermarsh can confirm, it's working now, ruff-lsp is not at fault in any way :) I've updated the issue at lsp-mode with my current configuration, it's pretty minimal, so I'd like to wait a day or two for feedback. Thanks again for the help!

[charliermarsh]

Awesome :)