From c9a2c8828fe3985bcd6b3e8b7ab6cf40c6e9ff18 Mon Sep 17 00:00:00 2001 From: Zhiming Wang Date: Thu, 4 Jun 2015 20:07:41 -0700 Subject: [PATCH] python module: pyenv-virtualenvwrapper support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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`. --- modules/python/init.zsh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/python/init.zsh b/modules/python/init.zsh index da78ea79..662c905d 100644 --- a/modules/python/init.zsh +++ b/modules/python/init.zsh @@ -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 #