Support multiple language servers per document

[sntgluca]

Description

Dear @krassowski , after the improvements achieved with jedi-language-server for autocompletion (#272), I am looking forward to configuring it to work with the code diagnostics features.

Unfortunately the latter doesn't work out of the box and I can't find any useful debugging/troubleshooting message to share.

Would it be possible to get some help to understand what code diagnostics expects and how to include its configuration? Many thanks

Reproduce

1. Install jedi-language-server as described in https://github.com/pappasam/jedi-language-server
2. Create a minimal server setting (See #272 for example)
3. Make a PEP8 mistake in the code

Expected behavior

Expecting seeing the Diagnostic Panel getting populated. Instead nothing happens.

Thanks!

[krassowski]

Have you tried configuring them with https://github.com/pappasam/jedi-language-server#configuration? Also, it seems that jedi by default only provides syntax error diagnostics so any PEP8 may need additional effort to make to work.

[sntgluca]

Hi, I tried a few "simple" variations on the Language Server in Advanced Settings, such as the following (jedils is the name I gave to my language server) but to no effect.

I don't know what else to try.

{
    "jedils": {
        "serverSettings": {
            "python.linting.flake8Enabled": true,
            "python.linting.pylintEnabled": true,
            "initializationOptions": {
                "markupKindPreferred": null,
                    "jediSettings": {
                          "autoImportModules": []
                    },
                    "completion": {
                        "disableSnippets": false
                    },
                    "diagnostics": {
                        "enable": true,
                        "didOpen": true,
                        "didChange": true,
                        "didSave": true
                    },
                    "workspace": {
                      "extraPaths": []
                    }
              }
        }
    }
}

I have no idea if this is easy or not, but from the documentation on jedy-language-server (and the fact that it's inspired by python-language-server) I was hoping something could be done.

Thanks for the fast reply!

[bollwyvl]

Started up https://github.com/conda-forge/staged-recipes/pull/13594 in case we want to start supporting/testing with this more formally. I for one am excited to see it in action, as I think pygls is great.

They recommend dls for more diagnostic stuff... it's probably worth investigating that, and doing more to handle multiple language servers that target the same (or many) language(s).

[bollwyvl]

dls in turn references efm-languageserver which appears to be a go-based generalized linter language server... the main bone to pick was the configuration file format (vim-style vs a novel one). As a casual vim user, that wouldn't bother me much, but would much rather package and support a single go binary than whatever it takes to roll out dls...

[bollwyvl]

Started up conda-forge/staged-recipes#13594

This was merged, should be up within the hour. One challenge: jls will probably always hard-pin to a particular version of jedi (currently 0.17.2). Can't say I blame them. Anyhow, I could imagine this eventually causing problems with ipython... presently it would actually be helpful but I could see a point at which having both of them installed might create problems. And having this and pyls installed at the same time is probably asking for trouble...

[krassowski]

FYI, jedi server is now auto-detected. Also, the built-in SyntaxError diagnostics fail because they have code: null which is a violation of the LSP protocol (see #diagnostics). There is already a fix in the works upstream, see: https://github.com/openlawlibrary/pygls/issues/124 and https://github.com/openlawlibrary/pygls/pull/132

This also affects other functions stability, e.g. hover.

[krassowski]

@sntgluca the workaround for jedi diagnostics was added in the last release, could you confirm if it works well for you?

[sntgluca]

Dear @krassowski and @bollwyvl, I am actually testing autocomplete these days, while exploring jupyterlab 3...

At first glance, I consider it significantly improved! I do wish to try for a bit longer to give a more reliable feedback though.

So far I can tell that it seems to have become helpful, pretty fast for local objects and small packages (i.e. sys). It gets slower when the packages are large (pandas, numpy or ipywidgets) but remarkably better than before. Notably, in these cases the direct kernel autocomplete is still faster... I see some inconsistency (+/- one second after caching), but it could be to my setup (remote connection, VPN)

Finally, I see almost all the features are implemented. I will try the newest version then and give feedback on the diagnostics ASAP!

I am really impressed by the constant progress. Kudos!

[sntgluca]

@krassowski,

I actually didn't answer your question below, did I? In my setup, I am using jupyterlab-lsp==3.2.0, jedi-language-server==0.21.0 and pygls==0.9.1, which seem to be the newest public releases (at least with conda).

The diagnostics panel only shows syntax errors. Do I have to change anything? Dependencies, configurations, updates? Is there some documentation I missed?

[krassowski]

This is expected, jedi-language-server only provides syntax errors. Good to have a confirmation that it is working well. We still intend to allow for having two different language servers per document (so that you could use completions from jedi-language-server and diagnostics from another language server) but this has no ETA (it would require some back-and-forth with design and thorough testing so it might happen during one of the future holidays unless someone will contribute earlier).

We just released jupyterlab-lsp 3.3.0 and jupyter-lsp 1.1.2 which bring more stability and performance improvements.