dominic/prezto
1
0
Fork 0
Code Releases Activity

python module: pyenv-virtualenvwrapper support

Browse source 
Previously the `python` module is fatal for folks using
`pyenv-virtualenvwrapper`, since `pyenv`'s `virtualenvwrapper.sh` is
designed for internal use by `pyenv virtualenvwrapper` rather than being
sourced. Basically, `pyenv`'s `virtualenvwrapper.sh` (in its `shims`
directory) calls `exec` on the actual `virtualenvwrapper.sh`, which
returns after making a few function defs and calling
`virtualenvwrapper_initialize`, so affected users can't even start a
shell session — it immediately returns.

In this commit I try to run `pyenv virtualenvwrapper` first, and check
for and try to load `virtualenvwrapper.sh` only if the former fails.

Also, a user-defined `WORKON_HOME` shouldn't be overwritten by the
`python` module, so I'm checking emptiness of `WORKON_HOME` before
setting it to `$HOME/.virtualenvs`.
This commit is contained in:
Zhiming Wang 2015-06-04 20:07:41 -07:00
parent 02c5f776fc
commit c9a2c8828f
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
modules/python/init.zsh
View file

@ -37,12 +37,12 @@ fi
# Load virtualenvwrapper into the shell session.
if (( $+commands[virtualenvwrapper.sh] )); then
# Set the directory where virtual environments are stored.
export WORKON_HOME="$HOME/.virtualenvs"
[[ -n $WORKON_HOME ]] || export WORKON_HOME="$HOME/.virtualenvs"
# Disable the virtualenv prompt.
VIRTUAL_ENV_DISABLE_PROMPT=1
source "$commands[virtualenvwrapper.sh]"
pyenv virtualenvwrapper 2>/dev/null || source "$commands[virtualenvwrapper.sh]"
fi
#