Document all the differences between similarly named packages

[maresb]

I feel guilty opening all these issues without PRs, but wanted to offer a fresh outside perspective. I hope you don't mind too much...

jupyter-lsp and jupyterlab-lsp look very similar, as do jupyter-lsp-python and jupyter-lsp-python-lsp-server. From the point of view of someone looking for a quick start, it'd be really convenient to have some reference table like:

• package name
• very short description
• when to install this or not

[bollwyvl]

This is kind of a "sausage-making" repo, and is almost entirely automated from changes to recipe/meta.yaml, and we don't control much of it (in return for it taking care of it building and shipping packages).

• package name

The README has a link to the different packages.

• very short description

Yeah, that's pretty much delegated to anaconda.org, where each package has a description with its short description. We can add a longer summary, but it's a crapshoot whether anaconda.org will update it.

• when to install this or not

I don't really know what that means.

[krassowski]

very short description/when to install this or not

I think it is best to delegate to the documentation of out project here: https://jupyterlab-lsp.readthedocs.io/en/latest/Installation.html. It certainly can be improved (PRs or concrete ideas welcome!).

package name

I believe that the idea with jupyter-lsp-python was to provide all in one package with pyls; jupyter-lsp-python-lsp-server was an equivalent for new pylsp but the naming is indeed not that helpful. In the ideal world we could use more descriptive names like jupyter-lsp-python-palantir, jupyter-lsp-python-community, and jupyter-lsp-python-jedi. I am not sure how disruptive such change would be. Would it help?

As for jupyter-lsp and jupyterlab-lsp we do want to keep the distinction to allow frontends other than JupyterLab to adopt it in the future. Edit: thinking more of it, maybe we could name the server extension differently like jupyer-lsp-server or jupyer-lsp-handler but again, changing it at this point may not be ideal. The distinction is already explained in https://jupyterlab-lsp.readthedocs.io/en/latest/Installation.html

[bollwyvl]

If it can at all be avoided, we don't want to change package names that have had multiple releases shipped. Since we _just_ started the new package, we could decide it's bad, and just never ship another one. Unfortuntely, the "community" upstream in this case has propagated, as there are already _a lot_ of things called python-language-something-something, a cleaner break to a distinct brand would have helped a lot of things (as would have perhaps going to pygls, but that ship has sailed).