Plan for plugins moving forward

[yeraydiazdiaz]

Hello, thanks for starting this community-driven fork 🙏🏻

I noticed that @andfoy has been creating issues in the repositories for different plugins but I wonder if a different approach would be benefitial.

I was thinking the newly formed python-lsp organisation would be a good place to gather these plugins so they're not only easier to find but can benefit from the shared experience of other plugin and pylsp contributors. These plugins could also be (re)published to PyPI with proper namespacing and maybe a classifier so they're easier to find.

@andfoy issues are certainly a step in the right direction, but frankly most of the plugins look quite abandoned and some of them already have forks that have been published independently (pyls-mypy for example was forked into mypy-ls), and I don't have high hopes they will be addressed soon, so, the only solution that comes to mind is forking, with all due respect to the authors of the plugins.

I hope this doesn't come across as confrontational, I genuinely would like to see an ecosystem of well-maintained plugins for pylsp.

[andfoy]

I think plugins can live in the organization, as long as the following conditions are met:

1. Someone is going to have to maintain them

Sadly, we (the Spyder team), won't have time to take over all the plugins

2. They would need to be renamed pylsp_*, e.g., pylsp_black, pylsp_mypy, etc

This is to distinguish them from the current existing plugins that work only with the old pyls. This change however may cause confusion to the users of the plugins that already are taking action to transition, such as pyls-memestra and pyls-spyder.

If we were to preserve the original pyls prefix, we would need to contact the original owners in order to get publishing permissions in PyPi, which may be difficult since the original plugins are unmaintained.

I think the best take here would be waiting for a few weeks in order to see if some plugin maintainers appear. I'll also publish a checkbox list here of all the pyls plugins, and which of those are already migrated.

Otherwise, if someone is able to volunteer for ownership for a specific plugin, they should comment here, in order to create a fork.

[andfoy]

After a thorough discussion with @ccordoba12, we decided to give the original plugins maintainers three weeks to perform the migration, after this period, which ends on May 18th, we will proceed to fork the plugins that were not migrated.

All the maintainers will be notified on the issues that were opened initially.

[yeraydiazdiaz]

I think there's not much point for plugins to support the original pyls, for example, pyls-memestra is not looking back. In my opinion python-lsp-server is the reference implementation now and plugins should just migrate or, if maintainers are unresponsive, forked.

It'd be great to have a PyPI package naming convention like pyls[p]-<NAME> for discoverability. Forked projects could use the extra p to distinguish or otherwise a PEP 541 issue can be opened for continued maintenance.

There is an edge case where the maintainer is responsive and willing to migrate but the package does not follow the convention, but I don't believe it would be a problem to rename the package to match. There could also be a list of plugins in this repo even if they don't all match the naming convention 100%, which is something that probably should exist regardless.

Whether or not they reside in the org is probably less important but probably benefitial, although I don't know what plans the Spyder team has for the org.

[krassowski]

I will also highlight that members of JupterLab team are happy members of the community and will help with maintenance of the plugins herein if given the chance. I also think that as long as original authors are responsive (see pyls-memestra), it should be fine for the plugin to live outside of the organization.

Maybe there should be a note in the reademe encouraging plugins (future or existing) to move to this organization in the future?

[andfoy]

@yeraydiazdiaz, we'll wait for some responses until May 18th, afterwards we can start delving into forks.

[andfoy]

Python Language Server plugins

Feel free to comment with your username if you are willing to give maintenance for a eventual fork.

• pyls-black: The plugin was forked into https://github.com/python-lsp/python-lsp-black and @haplo is willing to maintain it
• pyls-flake8: The plugin was migrated, thanks @haplo
• pyls-isort: The plugin was migrated, thanks @haplo
• pyls-mypy: Although there are plans to incorporate MyPy into the PyLSP core, a PR is ongoing on Depend on python-lsp-server pylsp-mypy#2 and one of maintainers is reviewing it.
• pyls-smart
• pyls-cwrap
• pyls-black-macchiato
• pyls-spyder: This one depend on us
• pyls-memestra: Thanks @marimeireles!

[s7726]

An attempt was made...
rupert/pyls-black#37

[haplo]

Feel free to comment with your username if you are willing to give maintenance for a eventual fork.

I'm willing to fork pyls-black, pyls-flake8 and pyls-isort, as those are the ones I use. Looks like pyls-flake8 maintainer is responsive, so that will probably not be necessary. Let's wait until the deadline for the rest.

Edit: I also use pyls-mypy, so count me in for that one too if needed.

[s7726]

@haplo I came here to reply that someone had responded to the pyls-black PR I made... Then realized that was you ;) Nice.

[haplo]

@haplo I came here to reply that someone had responded to the pyls-black PR I made... Then realized that was you ;) Nice.

Yeah sadly no response from a maintainer yet. If they remain unresponsive it should be easy enough to fork, change repository and package names to pylsp- prefix and release compatible versions.

[andfoy]

@s7726 @haplo Which plugins are you willing to maintain after May the 18th?

[haplo]

@s7726 @haplo Which plugins are you willing to maintain after May the 18th?

I use these plugins:

• pyls-black
• pyls-flake8
• pyls-isort
• pyls-mypy

I already have PRs for 3 of them, and @s7726 has one for pyls-black.

If we have to fork any of these plugins I propose doing so under the python-lsp organization. Then we can add multiple maintainers, I can be one of them.

[haplo]

pyls-isort now has a compatible release in PyPI. 🚀