When navigating from a virtualenv project directory, first deactivate the virtualenv.
Then, check to see if destination directory is also a virtualenv project directory.
If it is activate that virtualenv. See #5817.
Change error output to more conventional OMZ format, so it's clear the plugin is for oh-my-zsh and not base zsh.
Use `local` variables instead of manual unsetting.
Ubuntu and Debian store the system-installed virtualenvwrapper in
/etc/bash_completion.d/virtualenvwrapper, so that it gets automatically sourced
at startup in Bash. By not putting it somewhere in $PATH, they end up excluding
others (e.g. Zsh) that might want to use that file. Oops!
The virtualenvwrapper plugin should account for this so that Ubuntu (or Debian)
users don't end up with this message:
zsh virtualenvwrapper plugin: Cannot find virtualenvwrapper.sh. Please install with `pip install virtualenvwrapper`.
even when they have a virtualenvwrapper installed to a known location.
If user manually deactivates the virtualenv when using this mode, zsh
will produce following error:
deactivate:12: command not found: virtualenv_deactivate
To avoid this, check that the VIRTUAL_ENV flag is set before trying to
automatically deactivate the virtual environment.
Fixes#2185
Took me a while to figure this one out, and I have a default installation of virtualenvwrapper -- this is a soft fix, just put an error message. But perhaps the fix should be to use the default value `~/.virtualenvs`.
* removes cd override by using chpwd_functions
* removes subshell call to which by using $+commands array and
c param expansion to find in PATH
* zsh love!
Using lazy loading for virtualenvwrapper gives a mariginal speed
improvement and doesn't stop workon_cd from working. It has the
undesired effect of forcing you to call certain virtualenv commands
twice before they work (only once per shell instantiation).
