Does Rope need to be installed in the Project's environment?

[david-vicente]

Context: When using Jedi for completion, it is possible to have Jedi installed in the global environment of my system's Python installation. Then, for each project and respective virtual environment I can configure this globally installed Jedi to only consider completing stuff that makes sense locally, for both the packages installed in the active virtualenv and version of the python executable.

So if my global environment has a Python 3.9 and I install Jedi in this environment, and afterwards I create a project for Python 3.10 with just Numpy as a dependency, if I use Jedi in this project, it will give code completions that are relevant for Python 3.10 and Numpy.

Question : Does Rope allow for this, or do I have to install Rope my project's environment as a development dependency?

[lieryan]

Rope is just a library that can be used by different editor/IDE frontends, so the full answer to this is specific to each editor frontend.

By default, Rope needs to be able to find your project's dependencies and it looks for dependencies using the same mechanism that Python uses to lookup importable dependencies, modules installed to rope's own runtime environment will be autodiscovered; installing rope to your project's dev dependencies is the easiest way to get setup. You can also add additional paths by adding it to the python_path preference in the rope section of your pyproject.toml or dynamically using .ropeproject/config.py, your editor frontend may or may not have already automatically done this for you.

[david-vicente]

Thanks.

So if I get it correctly that means that rope has to be installed in an environment for a python version equal to the python version of he project that I'm editing.

I can extend the python_path of a rope in a python 3.9 environment to lookup modules in the environment of a python 3.10. But in that case I won't have completion for stuff that only 3.10 has. Am I correct?

[lieryan]

Yes, that's correct. rope uses the standard library's ast to parse Python code. So in the scenarios' you mentioned above, rope running on Python 3.9 will only be able to parse Python 3.9 syntax; it can't parse any code that uses any new syntax in 3.10 even if rope actually already support that syntax, as ast won't parse them.

It's usually preferable to run rope using the same version of Python as your project for that reason. If you're using rope with a server setup, like a python-lsp-server setup, or a subprocess setup, like neovim's Python provider, then you'll be able to much more freely use the appropriate python version to run rope.

[david-vicente]

Thank you for clearing that up for me.