pyvenv icon indicating copy to clipboard operation
pyvenv copied to clipboard

Support eshell

Open jorgenschaefer opened this issue 7 years ago • 4 comments

eshell currently ignores virtualenvs set by pyvenv. To support eshell, we need to set eshell-modify-global-environment to t and eshell-path-env to the path after activating and deactivating a virtualenv.

jorgenschaefer/elpy#1172

jorgenschaefer avatar Feb 02 '18 12:02 jorgenschaefer

I can send a quick pullrequest for this but the only question I have is whether to set eshell-modify-global-environment on init or put it in a method like pyvenv-initialize-eshell. It seems virtualenvwrapper.el first wrote that method and other packages, like conda.el, followed suite. It does add some functionality for aliases and such in eshell, which might be nice.

I guess I'll just implement the same and you can add feedback in the PR.

seanfarley avatar Feb 02 '18 19:02 seanfarley

Sounds awesome, thank you!

jorgenschaefer avatar Feb 09 '18 09:02 jorgenschaefer

Make sure there is some way of disabling this completely. In virtualenvwrapper.el you have to explicitly call (venv-initialize-eshell) to get eshell support.

Right now it is possible to have two different eshells that have different eshell-path-env values. You can start two different eshell by running the following code.

(eshell 1)
(eshell 2)

Say that you already have created two different virtual environments called foo and bar. And that these environments are located at in my case /home/henrik/.virtualenvs/foo and /home/henrik/.virtualenvs/bar

In eshell 1 execute the following elisp.

(setq eshell-path-env (concat "/home/henrik/.virtualenvs/foo/bin:" eshell-path-env))

In eshell 2 execute the following elisp.

(setq eshell-path-env (concat "/home/henrik/.virtualenvs/bar/bin:" eshell-path-env))

Then the output of which python in eshell 1 will be the following.

$ which python
/home/henrik/.virtualenvs/foo/bin/python

And the output of which python in eshell 2 will be the following.

$ which python
/home/henrik/.virtualenvs/bar/bin/python

In other words it is possible to have two different Eshell buffers that are using different virtual environments.

Changing pyvenv to support eshell is a good thing. But when you please don't break the above use case. My vote would be for having an explicit pyvenv-initialize-eshell method that the user has to call to enable support.

treadup avatar Mar 30 '18 18:03 treadup

Hi @jorgenschaefer , What's the status on this feature? This would be awesome to have in pyvenv.

jgarte avatar Nov 29 '22 15:11 jgarte