Elpy: Eshell does not recognize activated virtual env

[clearmisp]

If I open a new eshell when having a virtual env activated the eshell does not recognize the virtual environment. Is this supposed to work or have I configured elpy incorrectly?

Regards, Micke.

[clearmisp]

Opening a shell (M-x shell instead of M-x eshell) works, the new shell uses the activated virtual environment.

[jorgenschaefer]

Hello, and thanks for the report! This is strange. pyvenv sets exec-path, which should affect eshell, too. How do you notice that eshell is not recognizing the virtualenv?

[clearmisp]

1. I activate the environment using M-x pyvenv-activate.
2. I open a new eshell using M-x eshell.
3. In the new eshell I do 'which python', I get '/usr/bin/python' which of course is incorrect. If I do 'python --version' in the eshell I get 2.7.13, it should be 3.4.6.
4. elpy-config shows correct values of everything (I think).
5. The bin dir of the virtual env is prepended to exec-path, still I do not get the correct python in eshell.

I have tried to illustrate all this in a screenshot, I hope you can see all the info.

[jorgenschaefer]

Does M-: (executable-find "python") find the Python interpreter in the virtualenv?

[clearmisp]

It seem so. I evaluated (executable-find "python") in the scratch buffer and printed the result. At the same time eshell finds my system installed python, not the one in the virtualenv.

[clearmisp]

This is even more strange; executable-find evaluated in eshell returns the python in the virtualenv but the python command in eshell returns the system wide installed python.

[jorgenschaefer]

That seems to be a problem of eshell, I'm afraid …

[gopar]

@clearmisp I recommend using https://github.com/porterjamesj/virtualenvwrapper.el if you're using virtualenvwrapper. I've been using ti for a while and it works

[jorgenschaefer]

Hm. I'd be curious what virtualenvwrapper.el does that pyvenv.el does not, because Elpy recommends the latter. And I wrote the latter because there was nothing around that really worked well back then. If that changed, Elpy might want to switch suggested venv packages. Or some features could be added to pyvenv.

[gopar]

virtualenvwrapper will only work on eshell, it doesn't affect anything else. So pyenv is still the better route to go

[jorgenschaefer]

Oh. That's interesting, thank you :-)

[seanfarley]

It would seem that there is a missing eshell-modify-global-environment for pyvenv to work. The following works for me:

(setq eshell-modify-global-environment t)
(defun smf/post-venv-hook ()
  (setq eshell-path-env (mapconcat 'identity exec-path ":")))

(add-hook 'pyvenv-post-activate-hooks #'smf/post-venv-hook)
(add-hook 'pyvenv-post-deactivate-hooks #'smf/post-venv-hook)

It even works after the eshell buffer has started :-)

[jorgenschaefer]

Nice. Filed a feature request with pyvenv. I won't be able to work on this in the near future, so any help would be welcome :-)

[rafiks]

It would seem that there is a missing eshell-modify-global-environment for pyvenv to work. The following works for me:

(setq eshell-modify-global-environment t)
(defun smf/post-venv-hook ()
  (setq eshell-path-env (mapconcat 'identity exec-path ":")))

(add-hook 'pyvenv-post-activate-hooks #'smf/post-venv-hook)
(add-hook 'pyvenv-post-deactivate-hooks #'smf/post-venv-hook)

It even works after the eshell buffer has started :-)

this didn't work for me but virtualenvwrapper did.

[galaunay]

Apparently the associated PR in pyvenv has been merged.