python-language-server moving to python-lsp

[douglasdavis]

The python-language-server project has been forked and a new organization is continuing development at python-lsp-server (no one in the open source Python community has permission to merge PRs or cut releases in the palantir project, transition is ongoing here). The executable is changing names from pyls to pylsp. Creating this issue to suggest the lsp-pyls client transitions following the language server transition (and volunteering to help out when the server is ready)

[andfoy]

@douglasdavis, the first release of python-lsp-server is now up in PyPI: https://pypi.org/project/python-lsp-server/

[douglasdavis]

Thanks @andfoy!

I made a quick Emacs lsp-pylsp client package here (https://github.com/douglasdavis/lsp-pylsp). My question for the emacs-lsp maintainers: do y'all think it's appropriate to move it inside the emacs-lsp org? (I'd be happy to move it). Or to replace lsp-pyls with lsp-pylsp? Or neither 😄

[yyoncho]

what about changing the existing client to try pylsp and then if it is not present - use the old binary name? This will allow gradual transiton.

[yyoncho]

@mpanarin, any thoughts?

I want to have one client instead of 2 clients(one deprecated) and I don't want to be a breaking change because this leads to a lot of confusion and bug reports.

[mpanarin]

@yyoncho we definitely should move to the maintained package. I highly doubt that palatir will continue any support on the original ls

The only issue I see is python 2 support. But we probably can leave a message that for python2 you can try the microsoft ls.

[douglasdavis]

Is there an example of a client that tries one executable but falls back to another? Another concern would be the settings; needing to replace all occurrences of pyls.foo.bar with pylsp.foo.bar (the whole set is referenced below). Is there an example where the settings are defined on the fly?

lsp-mode/clients/lsp-pyls.el

Lines 427 to 479 in 78ccbc2

	(lsp-register-custom-settings
	'(("pyls.rope.ropeFolder" lsp-pyls-rope-rope-folder)
	("pyls.rope.extensionModules" lsp-pyls-rope-extension-modules)
	("pyls.plugins.rope_rename.enabled" (lambda () (eq lsp-pyls-rename-backend 'rope)) t)
	("pyls.plugins.autopep8.enabled" lsp-pyls-plugins-autopep8-enabled t)
	("pyls.plugins.yapf.enabled" lsp-pyls-plugins-yapf-enabled t)
	("pyls.plugins.rope_completion.enabled" lsp-pyls-plugins-rope-completion-enabled t)
	("pyls.plugins.pyflakes.enabled" lsp-pyls-plugins-pyflakes-enabled t)
	("pyls.plugins.pydocstyle.matchDir" lsp-pyls-plugins-pydocstyle-match-dir)
	("pyls.plugins.pydocstyle.match" lsp-pyls-plugins-pydocstyle-match)
	("pyls.plugins.pydocstyle.select" lsp-pyls-plugins-pydocstyle-select)
	("pyls.plugins.pydocstyle.ignore" lsp-pyls-plugins-pydocstyle-ignore)
	("pyls.plugins.pydocstyle.addSelect" lsp-pyls-plugins-pydocstyle-add-select)
	("pyls.plugins.pydocstyle.addIgnore" lsp-pyls-plugins-pydocstyle-add-ignore)
	("pyls.plugins.pydocstyle.convention" lsp-pyls-plugins-pydocstyle-convention)
	("pyls.plugins.pydocstyle.enabled" lsp-pyls-plugins-pydocstyle-enabled t)
	("pyls.plugins.pycodestyle.maxLineLength" lsp-pyls-plugins-pycodestyle-max-line-length)
	("pyls.plugins.pycodestyle.hangClosing" lsp-pyls-plugins-pycodestyle-hang-closing t)
	("pyls.plugins.pycodestyle.ignore" lsp-pyls-plugins-pycodestyle-ignore)
	("pyls.plugins.pycodestyle.select" lsp-pyls-plugins-pycodestyle-select)
	("pyls.plugins.pycodestyle.filename" lsp-pyls-plugins-pycodestyle-filename)
	("pyls.plugins.pycodestyle.exclude" lsp-pyls-plugins-pycodestyle-exclude)
	("pyls.plugins.pycodestyle.enabled" lsp-pyls-plugins-pycodestyle-enabled t)
	("pyls.plugins.pylint.enabled" lsp-pyls-plugins-pylint-enabled t)
	("pyls.plugins.pylint.args" lsp-pyls-plugins-pylint-args)
	("pyls.plugins.flake8.enabled" lsp-pyls-plugins-flake8-enabled)
	("pyls.plugins.flake8.exclude" lsp-pyls-plugins-flake8-exclude)
	("pyls.plugins.flake8.filename" lsp-pyls-plugins-flake8-filename)
	("pyls.plugins.flake8.hangClosing" lsp-pyls-plugins-flake8-hang-closing)
	("pyls.plugins.flake8.ignore" lsp-pyls-plugins-flake8-ignore)
	("pyls.plugins.flake8.maxLineLength" lsp-pyls-plugins-flake8-max-line-length)
	("pyls.plugins.flake8.select" lsp-pyls-plugins-flake8-select)
	("pyls.plugins.flake8.config" lsp-pyls-plugins-flake8-config)
	("pyls.plugins.preload.modules" lsp-pyls-plugins-preload-modules)
	("pyls.plugins.preload.enabled" lsp-pyls-plugins-preload-enabled t)
	("pyls.plugins.mccabe.threshold" lsp-pyls-plugins-mccabe-threshold)
	("pyls.plugins.mccabe.enabled" lsp-pyls-plugins-mccabe-enabled t)
	("pyls.plugins.jedi_symbols.all_scopes" lsp-pyls-plugins-jedi-symbols-all-scopes t)
	("pyls.plugins.jedi_symbols.enabled" lsp-pyls-plugins-jedi-symbols-enabled t)
	("pyls.plugins.jedi_signature_help.enabled" lsp-pyls-plugins-jedi-signature-help-enabled t)
	("pyls.plugins.jedi_references.enabled" lsp-pyls-plugins-jedi-references-enabled t)
	("pyls.plugins.jedi_hover.enabled" lsp-pyls-plugins-jedi-hover-enabled t)
	("pyls.plugins.jedi_definition.follow_builtin_imports" lsp-pyls-plugins-jedi-definition-follow-builtin-imports t)
	("pyls.plugins.jedi_definition.follow_imports" lsp-pyls-plugins-jedi-definition-follow-imports t)
	("pyls.plugins.jedi_definition.enabled" lsp-pyls-plugins-jedi-definition-enabled t)
	("pyls.plugins.jedi_completion.include_params" lsp-pyls-plugins-jedi-completion-include-params t)
	("pyls.plugins.jedi_completion.enabled" lsp-pyls-plugins-jedi-completion-enabled t)
	("pyls.plugins.jedi_completion.include_class_objects" lsp-pyls-plugins-jedi-completion-include-class-objects t)
	("pyls.plugins.jedi.environment" lsp-pyls-get-pyenv-environment)
	("pyls.plugins.jedi_completion.fuzzy" lsp-pyls-plugins-jedi-completion-fuzzy t)
	("pyls.plugins.jedi_rename.enabled" (lambda () (eq lsp-pyls-rename-backend 'jedi)) t)
	("pyls.configurationSources" lsp-pyls-configuration-sources)))

[yyoncho]

Is there an example of a client that tries one executable but falls back to another?

Something like that in :new-connection lambda should do:

(or (executable-find (cl-first new-pyls-binary-path))
     (executable-find (cl-first old-pyls-binary-path)))

Another concern would be the settings; needing to replace all occurrences of pyls.foo.bar with pylsp.foo.bar (the whole set is referenced below). Is there an example where the settings are defined on the fly?

Registering them 2 times should be good enough.

Given the differences, I will accept creating a new lsp-pylsp.el client and putting a warning in the old one, to migrate to the new one. The warning should print how one can disable that warning. If you decide to create a new one, the priority of the old one should be changed to -2 to have the new one with -1.

[deb75]

I heard that microsoft is deprecating its python language server. Can I still use it ?

Otherwise, which python language server do yo advocate ?

[douglasdavis]

deb75 ***@***.***> writes:

I heard that microsoft is deprecating its python language server. Can I still use it ?

The MS python-language-server is indeed deprecated in favor of Pyright+Pylance.

Otherwise, which python language server do yo advocate ?

IMO it comes down to personal preference. If you like the MS python-language-server, it still works fine but one must be aware that there is a chance it will get stale. If you don't mind installing a JS package as a Python language server, Pyright is a good choice and currently supported. If you want to use something supported by the larger open source Python community, that is written in Python, python-lsp-server is the currently supported project.

[microamp]

what about changing the existing client to try pylsp and then if it is not present - use the old binary name? This will allow gradual transiton.

@yyoncho

May or may not be related to what you suggested, but I tried changing lsp-pyls-server-command to ("pylsp") (previously, ("pyls")), but that does not seem to take any effect. It will still spin up a pyls process in the python-mode.

Given that python-lsp-server is still a young fork of the original python-language-server, I was hoping it would just work by swapping out the variable above. It's probably not as straightforward as that.

[yyoncho]

@microamp after #2846 it should be all good.

[mpanarin]

Mmmm, I don't think that just switching the server is a good idea. Pyls is stable as is and, while unmaintained, there was no response from palantir that it is abandoned. Plus, as new server is being developed there is a high chance of incompatibilities between them.

So keep the old pyls as a backup server with a warning of deprecation. At least for now