Elpy: Where should the jedi/rope installations that elpy is using be installed when using a virtualenv?

[IvanMalison]

This is not really an issue so much as a question about how one is supposed to operate when they are using elpy.

When I activate a virtualenv with pyvenv elpy is typically (understandably) unable to find the global jedi/rope installations that I have on my machine. I am aware that it is possible to make it so that virtualenvs allow access to global site-packages, but it is generally regarded as a bad practice to do this.

Is elpy's expectation then that jedi/rope should be installed in each virtualenv that they are being used in. This seems like a not so great solution because it is very manual/it requires to pollute your virtualenv.

I'm not sure that there is a good solution to this issue, but I'd like to hear what you do to get around this issue

[jorgenschaefer]

Hello, and thanks for the question!

This is a somewhat tricky problem, as you can't really activate two virtualenvs at once. You have a few options here.

First, you can of course install Elpy, Jedi etc. in every virtualenv. This can be a bit annoying as you note, but it's not completely unusual – test runner, mocking libraries and other development tools are installed regularly in all virtualenvs. Elpy etc. are development tools just the same. But then, they are somewhat developer-specific.

Second, you can install these packages in a separate virtualenv and just add $VIRTUAL_ENV/lib/python*/site-packages/ to your PYTHONPATH or to your virtualenv using add2virtualenv. You have to be careful and use the same Python version for both virtualenvs, but otherwise, this works.

Third, you can install Elpy and the other packages globally (or user-local) and use the --system-site-packages argument to virtualenv or virtualenvwrapper's toggleglobalsitepackages to give your virtualenv access to those packages.

Does this help?

[IvanMalison]

Does this help?

Hah. Well I was already aware of all of these potential solutions and I didn't really particularly like any of them, but its good to know that this is a known issue.

test runner, mocking libraries and other development tools are installed regularly in all virtualenvs. Elpy etc. are development tools just the same. But then, they are somewhat developer-specific.

AS you mention jedi and rope are really developer specific tools, and they shouldn't really be added to the repo, even as a dev only dependency.

I definitely feel as though the cleanest solution is to somehow access the global install of jedi/rope. I didn't know about virtualennvwrapper's toggleglobalsitepackages. I guess that seems like a somewhat promising solution. It might be cool to build something into pyvenv/elpy that allows the user to toggle this toggle. That would make the cognitive load associated with dealing with this problem a lot more manageable.

At the very least, I think it might make sense to add something about this in the readme

[jorgenschaefer]

At the very least, I think it might make sense to add something about this in the readme

Indeed (documentation, not the readme, but same thought). I'll leave this issue open for that, thanks again!

[chenl]

It has been > 3 years since the last comment on this issue. Is there any new recommendations with regard to the original question?

Also when using pipenv, installing with pipenv install --dev jedi might be the wrong thing to do, since it will update the Pipfile that should be committed into the VCS, and thus other developers on the team will install it even if they are not using Emacs :scream:.

[galaunay]

At the moment, you still need to have jedi installed in the virtualenv.

But there is a PR (#1548) in progress to address this.
This would make Elpy's rpc (responsible for completion/code navigation/...) use the global site-packages instead of the virtualenv one.
This way you would just need jedi to be installed globally.

However, It is a delicate change internally and it may take a bit of time to reach the master branch.

[gopar]

@chenl are you able to do pip install jedi instead of pipenv install --dev jedi? This will let you have jedi without touching the Pipfile which is what I've been doing in the past months.