Provide a 'glue' library for VSCode?

[alcarney]

I have a fair amount of code in esbonio dedicated to just managing Python envs and installing/updating the language server - it would be good to get more eyes on this and it's a problem any pygls powered language server would be looking to solve.

Another common problem to solve would be standing up a pyodide environment - assuming projects are interested in supporting VSCode web extensions.

I just thought I'd ask and see if there was any interest in creating a common library for this sort of thing? Also if such a library was made, could it live in the pygls repo? Or would we prefer it to be something separate?

[dgreisen]

I like this idea.

The two times I started a pygls project, I ended up copying the json example, trying to strip away the things I didn't need, and going from there. What if we created a new repo that was a truly bare bones implementation with NotImplemented exceptions everywhere you must replace stuff. Then it would be as simple as cloning the repo to get started. If we wanted to get fancy, we could implement the json server in a branch of that repo.

If you like this idea, I'm happy to create the repo and give appropriate permissions. maybe pygls-template or pygls-start?

[alcarney]

Ooh nice - perhaps it could be implemented as a cookiecutter template?

I think however, it’s not quite what I was getting at… I was thinking about publishing a module on npm that people can use to automate installation/updates of their language server etc. Such a module could be included in the json example/pygls-template repo though.

[dgreisen]

I have no opinion on use of cookiecutter. Maybe it could be useful for creating multiple project types? e.g. bare pygls server package or vsix with pygls and pygls-vscode-client or pyodide?

ah. gotcha. that makes sense. I can see advantages and disadvantages of a separate repo. Happy to create separate repo if you like. Maybe pygls-vscode-client?

Give me explicit instructions:

name of cookiecutter repository, if any
name of client repository, if any

[alcarney]

If we did anything I'd probably vote for just the client repo for now, (and vscode-pygls-client seems as good a name as any) but do you think it's worth holding on for a bit to see if there's some interest in this?

[dgreisen]

happy to hold off. Just let me know if/when you want me to do something!

[dgreisen]

This might be crazy, but it could be really cool to create a pygls server for pygls. that would make it incredibly easy to start a new project, and add features like autocomplete, progress notifications, etc?

Might be a much more fun and actually useful tutorial project, instead of/in addition to json?

[alcarney]

I like the idea! Though I'm struggling to picture what it would do beyond a regular Python language server 🤔 ... offer CompletionItems with snippets of pygls code perhaps?

[dgreisen]

yeah - that's what I was thinking - autocompleted features.

[brettcannon]

I'm not sure to what extent you want "glue" for VS Code, but we are working on a GitHub repo template to make it easy to stamp out VS Code extensions which wrap Python CLI tools. It's built on top of pygls as we are using LSP to drive the tools. We are hoping to take it public in a month or so, but it's already being used for our Pylint, Black, and isort extensions.

[alcarney]

Perhaps glue wasn’t the best word choice… but to be specific I think there are two use cases that make sense to be handled by some helper library

• For the desktop version of VSCode, ensuring that the Python package providing the server is available in the configured Python environment, installing/updating it if required. - Is that something the template handles?
• For the web version of VSCode, basically packaging the code found in this file which sets up a Pyodide environment and handles communication with the server. There’s probably a right way to do this and it would be good for extensions not to have to reinvent it each time.

[brettcannon]

• For the desktop version of VSCode, ensuring that the Python package providing the server is available in the configured Python environment, installing/updating it if required. - Is that something the template handles?

No because we actually ship all the code in the extension itself as part of the template. So the pylint language server, for instance, is simply part of the extension and we use pip to install to a specific directory at extension build time to ship the dependencies as appropriate.

• For the web version of VSCode

We haven't tried to tackle vscode.dev yet. Pyodide won't work for tools we are wrapping which want access to files. The VS Code team is looking at using WASI, though, to make things work using VS Code file APIs, so assuming that work pans out we will look at using that.

[alcarney]

The VS Code team is looking at using WASI, though, to make things work using VS Code file APIs

That sounds interesting! Is there an issue somewhere I can keep an eye on?

[brettcannon]

Not yet; it's all an experiment (albeit one that looks promising).

[tombh]

Wow, I love the idea of a Pygls Pygls server. I think it's always good to have the virtuous cycle of "dogfooding", not all projects can consume themselves, and so any that can should strive to do so. Though, from what @brettcannon is saying (in #257 as well), and if I'm understanding correctly, we could actually go a step further, or rather a step deeper, and make what would be perhaps better described as a Pygls-flavoured LSP LSP server. I'm imagining something that would be used more as a suped-up LSP in debug mode. So in the JSON example the list of code actions for a given token wouldn't just be what's already been implemented (with links to the custom LSP code that does implement it) but also what could be implemented (with links to the parent Pygls code that generalises it) according to the LSP standard. I don't know how feasible or ultimately useful all this is, but at the very least I love the thought experiment of it.

Anyway, back to the original topic! I've never actually used VSCode, so my only experience of LSP is from Neovim, which also has native LSP support. Here's how you setup esbonio in Neovim for example. How similar is that to VSCode? Is the nvim-lspconfig plugin roughly equivalent to your suggestion of a glue library?

Also, I'm not familiar enough with Python packaging to know what the consensus is on solving dependency issues like we had with Pydantic (namely overly strict version requirements that conflicted with common system versions of Pydantic, discussed in #221). Could such issues be addressed by a glue library?

[brettcannon]

'm not familiar enough with Python packaging to know what the consensus is on solving dependency issues like we had with Pydantic (namely overly strict version requirements that conflicted with common system versions of Pydantic, discussed in #221).

There's not much you can do. Python only allows you to have one version of a package installed at any one time in an environment, so as a library you effectively need to be as loose as possible with your requirements so you don't force restrictions on your downstream users. Usually you work around this by making a new release that raises your minimum version requirement on whatever library you're having problems with and anyone who is stuck on the older version of the library uses the older version of Pygls. (And you should definitely avoid setting a max version restriction; see https://iscinumpy.dev/post/bound-version-constraints/ for details.)

[tombh]

Thanks for the explanation @brettcannon

[alcarney]

How similar is that to VSCode?

Quite similar, the Esbonio VSCode extension is passing similar arguments to a LanguageClient instance provided by the vscode-languageclient library.

Is the nvim-lspconfig plugin roughly equivalent to your suggestion of a glue library?

Not quite… perhaps a closer analogue would be the nvim-lsp-installer plugin, but without all the fancy UI bits.