Configuration of LSP rules

[shapiromh]

I was playing with the new basedpyright integration in the 0.14.16 release and found the default rules will tag unused call results with a warning. In a notebook context this results in a lot of warnings, so I tried following basedpyright's instructions for disabling those warnings. I could not figure out the right place to include those custom rules and whether marimo's lsp server would actually respect those rules.

In my project directory I tried a few ways to make a configuration. In my pyproject.toml, I tried both

[tool.basedpyright]
reportUnusedCallResult = "none"

and (based on seeing the global marimo.toml file layout)

[tool.marimo.language_servers.basedpyright]
reportUnusedCallResult = "none"

I also tried creating pyrightconfig.json file with the rule enabled. Is there a known correct way to set up this configuration or is it not possible with the current implementation?

[mscolnick]

@winstxnhdw added our pyright support (thank you again!). tagging him in case he has some tips to get this set up

[winstxnhdw]

We pass the documentRootUri to the LSP so I had thought that basedpyright would automatically search the path for a valid config file and use those configurations. Perhaps we may need some mechanism to enumerate the config within pyproject.toml and pass it to the LSP via JSON-RPC? @DetachHead does basedpyright not search the root path for pyproject.toml?

[DetachHead]

pyright and basedpyright should find a pyproject.toml in the project root. I'm not familiar with Marimo though so I would need to investigate further to determine whether or not this is an issue on my end

[DetachHead]

i can't seem to figure out how to enable basedpyright in the marimo editor. looks like the docs haven't been updated to mention it. i tried enabling it here in the settings but it had no effect:

as for the rule OP is trying to disable, ideally it should not be reported on the last line of a notebook cell in the first place. i've opened DetachHead/basedpyright#1440 to track this

[winstxnhdw]

I forgot to update the docs, but ticking both of these options with basedpyright installed in your environment is sufficient. Sometimes you might have to restart the kernel once before the diagnostics start showing up.

[DetachHead]

ok after playing around with it for a bit and comparing the initialize requests sent by both the vscode extension and the marimo editor, i'm fairly certain i've identified the issue.

vscode

marimo

{
  "jsonrpc": "2.0",
  "id": "0",
  "method": "initialize",
  "params": {
    "capabilities": {
       // ...
    },
    "processId": null,
    "rootUri": "file:///home/me/projects/basedpyright",
    "workspaceFolders": []
  }
}

i see that marimo doesn't send any workspaceFolders or a rootPath (the same as rootUri without the file:// part), which means nothing gets initialized here. i think updating marimo's lsp client to send either of them fixes the issue.

note that the file watching functionality will still need some work i think, otherwise changes to pyproject.toml will still require restarting the server. i'm not sure exactly what that entails for non-vscode editors though. i once tried to make basedpyright fall back to its own file watcher when client doesn't have one but that didn't work very well (see DetachHead/basedpyright#1043)

[winstxnhdw]

Thank you! That’s very insightful. This is certainly unintended. I’ll try to get a fix out.