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`.pull/898/head
parent
02c5f776fc
commit
c9a2c8828f
Loading…
Reference in new issue