GeezerVison is showing github.com — Plan for plugins moving forward · Issue #27 · python-lsp/python-lsp-server
Plan for plugins moving forward #27DescriptionHello, 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. Reacted by Michał Krassowski, Michael Weimann, jdhao, Rocky, nyngwang and Felipe S. S. Schneider Reacted by Rocky, nyngwang and Felipe S. S. Schneider Activityandfoy commented on Apr 29, 2021 I think plugins can live in the organization, as long as the following conditions are met:
- Someone is going to have to maintain them
Sadly, we (the Spyder team), won't have time to take over all the plugins
- 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 commented on 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 commented on Apr 29, 2021 ContributorAuthor More actions 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. Reacted by Michał Krassowski krassowski commented on 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 commented on Apr 29, 2021 @yeraydiazdiaz, we'll wait for some responses until May 18th, afterwards we can start delving into forks. andfoy commented on 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 commented on May 1, 2021 haplo commented on May 13, 2021
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 commented on 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 commented on 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.
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 commented on May 13, 2021 @s7726 @haplo Which plugins are you willing to maintain after May the 18th? haplo commented on May 14, 2021
@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 commented on May 14, 2021 pyls-isort now has a compatible release in PyPI. 🚀 Reacted by Edgar Andrés Margffoy Tuay, Jonathan Jin, jdhao and nyngwang haplo commented on May 18, 2021 Status update:
- pyls-flake8 accepted the PR, but has yet to release a new version to PyPI.
- pyls-mypy is unresponsive, and from other comments has been for months. It looks like there is no actively maintained fork, so my recommendation is to fork as python-lsp/lsp-mypy, make necessary changes and release as lsp-mypy package to PyPI. I can also fork at haplo/lsp-mypy and handle the release to PyPI, just let me know.
- No response from pyls-black. I can fork it and maintain it unless @s7726 wants to handle it.
haplo commented on May 19, 2021 @andfoy I created a PR that updates the README to point to the new forks. igo95862 commented on 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 commented on Nov 22, 2021 @igo95862, it could be discussed as long as someone takes ownership of it igo95862 commented on 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 commented on 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-ruff which could be kept independent or even made to be built-in if preferable. haplo commented on 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-ruff which could be kept independent or even made to be built-in if preferable.
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-server IMO. ccordoba12 commented on Nov 14, 2023
I'm +1 to removing all built-ins, and have people install the ones they need.
That's more or less the case right now. I mean, if you install python-lsp-server you'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 commented on 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 commented on 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.
Rope, but it's not as feature complete.
Would you be open to PRs to extract yapf, rope, autopep8, etc. into separate plugins?
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-server and python-lsp-ruff, you'll get all that you need (for people that wants to use only Ruff). haplo commented on Nov 15, 2023
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).
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.
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-server and python-lsp-ruff, you'll get all that you need (for people that wants to use only Ruff).
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 commented on 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.
Thanks for understanding.
I like that idea.
Great! Could you submit a pull request for that? We can include it in our next minor release (1.10.0). mcepl commented on Jun 6, 2024 Reacted by Carlos Cordoba
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|