Document editors, libraries, and LSP projects with rope support

[lieryan]

Document all known first and third party projects that supports rope, how to use rope in those environments, and the state of their integrations. This should be linked in the README for visibility to users who stumbled into this project and wants to quickly know the best option they have to integrate rope to their development environment.

...

Subtasks:

• Create first draft to Document editors, libraries, and LSP projects with rope support #384
• Break this ticket by editors and/or integration
• Expand documentation of Vim support in the Wiki #415
• Expand documentation of Emacs support in the Wiki #416
• Expand documentation of LSP support in the Wiki #417

[lieryan]

(draft)

There are currently three options for using rope in Vim:

• ropevim is the reference implementation maintained by the rope project. Though there are some rough edges in the UI, it's one of the more fully featured rope integration. The way this plug-in is designed and implemented, it doesn't actually need that much maintenance, so its sparse update rate can be quite misleading.
• python-mode is the one that I personally use and have used for a long time. It does include many other tools other than just refactoring with rope, and it doesn't support all of rope's feature and options but the ones that it does implement works very well, and I also occasionally work on that project to improve its rope support as well.
• Palantir Python LSP. There are two iterationsof this project, the Palantir version of this LSP project (pyls, GitHub) seems to be dead, but a community fork (pylsp, GitHub) ran by Palantir's former maintainers is still alive and kicking. I recommend using the community fork instead of the original Palantir one. I don't really use this LSP that much at the moment, but one way or the other it'll likely be a cornerstone of rope's future in the LSP space.

There's also a potential forth option:

• rope-language-server is an experimental fork of Palantir's LSP by one of rope's own main maintainer. This project is not ready for prime time yet and is currently on hold. Not recommended for use.

[mcepl]

* [rope-language-server](https://github.com/mcepl/rope-language-server) is a fork of Palantir's LSP by one of rope's own main maintainer. This project is not ready for prime time yet and is currently on hold.

And currently is dead. I can transfer it to the python-rope if you care about it, but I don't think it is worthy: it is not much more than a small fork of the original rather old commit of the Palantir Python LSP, with some non-rope functionality removed and replaced by rope, but really not that many. I think it would be nice if something like that was written, but I am not sure this is it.

And yes, I think that LSP is the future, and if rope wants to survive, it should be fully used by some LSP servers (“fully” meaning not just used for few refactoring functions before the LSP server gets better implementation, but used for everything rope is providing).

[lieryan]

After evaluating the landscape of LSP; currently, I think our best bet for moving into LSP space is by creating a python-lsp-server plug-in rather than forking python-language-server or python-lsp-server itself, the way that rope-language-server was doing. python-lsp-server has a plugin system that would allow 3rd party plugins to hook new functionalities into python-lsp-server.

python-lsp-server already has a first party rope plugin, but, as you said, it barely scratches the surface of rope's refactoring functionality. Currently, it only seem to provide renaming and completion.

We'll need it to implement more functionalities into it or create a third party rope plugin for python-lsp-server to make rope a more viable/competitive option there.

[mcepl]

Yes, but I was really thinking about more of rope even into the fundamental operations (go-to-definition), and ideally to make it so that the model of the document which is in memory IS the rope’s one. However, I won’t be writing this, so whatever whoever decides is their problem. rope-language-server is dead then.

[lieryan]

Personally, I'm happy to let users decide if they want to mix and match pylsp plugins. If they want to use Jedi for completion and definition jumping, but rope for refactoring, then they should be allowed to have that choice, rather than being forced to choose between jedi-only LS and rope-only LS.

Rope's core strength is refactoring operations, so that's where I want to focus my development effort, at least until we have a larger number of active contributors/maintainers to support the capacity to look after the other parts of Rope.

The way I see it, our real competition here isn't other open source tooling like Jedi or isort, even when there are definitely some (or a lot) of overlaps between these projects, but rather closed source language servers like Pylance or PyCharm.

[mcepl]

If pylsp allows this level of granularity, than good for us. Otherwise, all good points. And concerning the competitive scene, I would say https://github.com/Microsoft/python-language-server is somewhere on the top of the list.

[seamuswn]

pylsp has some pretty serious issues which makes it somewhat unusable in a lot of contexts:
python-lsp/python-lsp-server#114
python-lsp/python-lsp-server#625
python-lsp/python-lsp-server#503

I think in general, having separate LSs makes a lot of sense and having a dedicated rope LS would be valuable. It's not forcing people to choose between jedi-only and rope-only, but rather that jedi LS would provide the syntax highlighting, go to symbol, etc support, and rope LS could enrich the developer experience by offering additional code actions for refactoring.

This is the direction ruff has started moving in

[mcepl]

rope-language-server has been reviewed (and mostly vibe-coded) as https://codeberg.org/mcepl/rope-language-server/ . Feel free to mirror to this organisation, issues should stay on Codeberg.