Add standalone language server executable for other editors to consume

[dsifford]

Hi there. Awesome project!

Is your feature request related to a problem? Please describe.

Perhaps this is already possible in the distributed package but I wasn't able to figure it out. What I'd like to do is consume the LSP server this project defines in vim (using ALE).

As an example, here's how the pylint LSP server is able to be consumed in ALE... https://github.com/w0rp/ale/blob/master/ale_linters/python/pyls.vim

Describe the solution you'd like

Add an ability to invoke the language server from the command line. (If not there already).

[erictraut]

This is outside the scope of this project. If you want to start another project to provide the necessary glue to host Pyright or other LSP servers in other editors, please feel free to do so.

[w0rp]

Could you offer any advice on how to build a command line utility for starting the language server? Without a CLI utility, the language server cannot be used outside of VSCode, or in some other editors not written in JavaScript.

[erictraut]

Here are a couple of pointers...

The pyright.ts code file implements the command-line interface provided by Pyright today. It's a small wrapper around the analyzer service.

The language server is implemented in server.ts and is also a small wrapper around the analyzer service. The language server uses VS Code APIs to communicate with the VS Code language client.

If you want to support other editors, you can create a new project and specify pyright as a dependency through the package.json file. Then create a new top-level code file that imports the analyzer service. You'll need to instantiate it (it's a singleton class) and call it as appropriate (e.g. in response to various events from your language service client). You can use pyright.ts and server.ts as examples of how to call it.

Hope that helps!

[w0rp]

Cool, thank you for the information.

[lkgarrison]

@erictraut I'm unclear why a separate project needs to be created in order to use the Language Server instead of being able to run it from this project. Is it too tightly coupled with VSCode? Or would it need an additional CLI command to start up the language server that is undesirable to add? I was surprised to see you push for a separate project that would expose the language server for other IDEs. It seems a bit silly and against the spirit of LSP to develop a tool like this that is only compatible with VSCode?

[erictraut]

I'm not familiar with what it takes to package an LSP independently and integrate it with other editors.

It's likely that there will be some compatibility issues with other language server clients, since the current pyright code assumes that certain features are available in the client. That could certainly be addressed, but I don't plan to investigate, maintain or test compatibility with other clients.

My goal with this project was to create a great VS Code plugin plus a stand-alone CLI. If you want to use it for something other than this, you're welcome to do so.

[w0rp]

I think it would make sense to create a separate package for a CLI, which could read and write JSON via stdin and stdout. I have seen other projects that work the same way.

[fannheyward]

Hello all, you can use pyright in vim/neovim with coc-pyright+coc.nvim. https://github.com/fannheyward/coc-pyright

[WhyNotHugo]

I'm a bit confused as to what the issue would be in providing support for running the language server as a CLI.

• The LSP itself is implemented.
• There's a CLI already implemented.

It just seems like a CLI command to start the server is all that's needed. Adding this into this project would seem to be trivial, but creating a separate project would require all the scaffold of a cli application (which is already in-place here), and that project would do nothing of its own, just start the server (which is already in-place here too).

In short, that project ("pyright-lsp") would really do nothing of its own, just provide an entry point, which is one does all the actual work. Not only does this require a lot of scaffold and add extra complexity, it'd provide an extremely confusing end-user experience.

Would you be willing to accept a PR that adds the command into pyright? Right now pyright implements a standard protocol which can be reused by any editor, but merely lacks the ability to run it unless the editor is written in node.

[erictraut]

I won't commit to accepting a PR before I see it, but I'll consider it. It will depend on the amount of complexity and maintenance burden it adds to the project. If it's as trivial as you seem to think it is, then it sounds reasonable. If it's moderately complex, then I still think it would be better for it to be part of its own project that imports pyright as a dependency.

[zeronone]

I created a PR related to this issue, please let me know what you think about it.
#810

[erictraut]

Thanks for the contribution. I haven't tested it, but I presume you have. The changes looks good to me.