Start the LSP server automatically when JupyterLab starts

[krassowski]

Maybe this could be implemented as the extension server companion?

[fcollonval]

Hey thanks for working on this.
I experiment a bit with the Monaco editor. And in particular, I achieve to start lsp server from a server extension.
Here are the references
jupyterlab/jupyterlab-monaco#22
https://github.com/fcollonval/jupyter_python_languageserver

[krassowski]

Thank you for pointing me to this extension - it seems like a very good idea!

I would like to keep the language-agnostic approach - could your extension be modified to work with any LSP server? I have no prior experience with tornado but if this was flask I could easily load servers.yml config file, create routes, one per the LSP server and run the servers in subprocesses; I bet this is doable with tornado as well (and just by looking on the existing code I see one could make a class factory for the handlers, substituting the command, though it seems like a hack).

I do not know what would be more user-friendly - having to install multiple server extensions (one per language) or having to prepare servers.yml for "one for all" server extension (the latter would be easier to maintain). What do you think?

[fcollonval]

The first approach (install multiple server extensions) is the best approach if you look at the use case:

• I'm user of jupyterlab. I know it supports lsp. So I want to use the lsp for like ruby, I do conda install jupyter_lsp_ruby. And that's it.
  On the opposite with the second approach, I need to install the dependencies/executable needed. And maybe some plumbing in the server.yml, if the language is not present or if I don't want the default server (for example python lsp has already multiple implementations).

The first approach is definitely the one promoted by LSP and Jupyter. If you look at VS Code, you do exactly that, install an extension per language you need. If you look at Jupyter, same for the kernels.
In addition it will reduce the maintenance cost as the only interface you will need to handle is what's the endpoint to start the lsp server and to be promoted to websocket. That's what I was suggesting in the PR for Monaco. Something like jlabUrl/lsp/language (this is exactly what's done by the Json rpc server but only as a single server).

One last thought, using the server.yml this presumes you need to start a local process to handle lsp request. What if you want to defer them to a remote server? With the first approach it's possible but this is out of scope of this package. With the second one this means you would need to handle request forwarding or local process.

[krassowski]

Thank you for the detailed response. Your arguments have a lot of merits, I think that you changed my mind.

The only thing that I am still slightly worried about is the case if there is no LSP package ready for certain language - but then if the documentation is good enough and a template is provided, it should be easy for anyone to create a new LSP package (though not as easy as with server.yml).