Repository navigation
Plan for plugins moving forward #27
Description
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.
Activity
andfoy commentedon Apr 29, 2021
I think plugins can live in the organization, as long as the following conditions are met:
Sadly, we (the Spyder team), won't have time to take over all the plugins
pylsp_*, e.g., pylsp_black, pylsp_mypy, etcThis 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 commentedon Apr 29, 2021
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 commentedon Apr 29, 2021
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 extrapto 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 commentedon Apr 29, 2021
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 commentedon Apr 29, 2021
@yeraydiazdiaz, we'll wait for some responses until May 18th, afterwards we can start delving into forks.
andfoy commentedon Apr 29, 2021
Python Language Server plugins
Feel free to comment with your username if you are willing to give maintenance for a eventual fork.
s7726 commentedon May 1, 2021
An attempt was made...
rupert/pyls-black#37
haplo commentedon May 13, 2021
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 commentedon May 13, 2021
@haplo I came here to reply that someone had responded to the pyls-black PR I made... Then realized that was you ;) Nice.
haplo commentedon May 13, 2021
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 commentedon May 13, 2021
@s7726 @haplo Which plugins are you willing to maintain after May the 18th?
haplo commentedon May 14, 2021
I use these plugins:
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 commentedon May 14, 2021
pyls-isort now has a compatible release in PyPI. 🚀
haplo commentedon May 18, 2021
Status update:
7 remaining items
haplo commentedon May 19, 2021
@andfoy I created a PR that updates the README to point to the new forks.
Use pylsp instead of pyls
igo95862 commentedon Nov 21, 2021
Can a plugin be upstreamed in to this repository? (for example, there is a flake8 plugin in default installation and as a third party plugin)
andfoy commentedon Nov 22, 2021
@igo95862, it could be discussed as long as someone takes ownership of it
igo95862 commentedon Nov 23, 2021
I am kind of interested in official mypy plugin. It is a pretty big project made by python creators. Although it should be some way opt-in as a lot of projects are not typed. Mypy has a specification for configuration file so maybe it should only activate if the config file is present.
doolio commentedon Nov 8, 2023
Has there been any thoughts about removing the built-in plugins entirely to simplify the codebase? I'm thinking many of the built-in plugins could be replaced by
python-lsp-ruffwhich could be kept independent or even made to be built-in if preferable.haplo commentedon Nov 8, 2023
I'm +1 to removing all built-ins, and have people install the ones they need, everything properly documented of course, including a directory of known plugins. This should be OK with a new major version of
python-lsp-serverIMO.ccordoba12 commentedon Nov 14, 2023
That's more or less the case right now. I mean, if you install
python-lsp-serveryou'll only get code completion, go-to-definition and hovers with Jedi. All the other of functionality is opt-in by installing Yapf, rope, Autopep8, etc.The problem I see with splitting the project into multiple plugins is that it'd make maintenance harder. And since I'm the only maintainer, I'm -1 on it because I'm also in charge of a lot of other stuff.
haplo commentedon Nov 14, 2023
Jedi has no alternative AFAIK, right? In that case it makes sense to keep it built-in, as long as the rest are optional installs.
Would you be open to PRs to extract yapf, rope, autopep8, etc. into separate plugins?
ccordoba12 commentedon Nov 14, 2023
Rope, but it's not as feature complete.
Nop, due to what I said. That would require for me to maintain not a single project but 5 or 10 of them (i.e. make releases, keep them in sync and in general spread my attention between several repos).
What we could do is to modify the defaults to not endorse any linting or formatting library at all. That way, if you install
python-lsp-serverandpython-lsp-ruff, you'll get all that you need (for people that wants to use only Ruff).haplo commentedon Nov 15, 2023
I think I speak for everyone when I thank you for your maintenance effort, anything that makes your life easier is good.
If the optional parts are neither installed nor enabled then it should be OK IMO.
I like that idea. Currently many plugins (thinking of python-lsp-black and python-lsp-ruff) disable other plugins in their default configuration, this could be a way to clean that up.
ccordoba12 commentedon Nov 15, 2023
Thanks for understanding.
Great! Could you submit a pull request for that? We can include it in our next minor release (1.10.0).
mcepl commentedon Jun 6, 2024
There is https://github.com/python-rope/pylsp-rope which is built for THIS Python LSP server, not the old one.
Use pylsp instead of pyls
Use pylsp instead of pyls