Just having 'pyenv' available doesn't imply availability of virtualenv pyenv
plugins. Check for availability of virtualenv plugins as well before attempting
to use pyenv wrapper for virtualenv.
Changes:
* Simplify zstyle name `skip-virtualenvwrapper-init` to `initialize`
avoiding double negation in name
* Always perform `eval (pyenv virtualenv-init -)` at initialization
* Prefer `virtualenvwrapper_lazy` over `virtualenvwrapper` when available
* Honor `VIRTUALENVWRAPPER_VIRTUALENV` if it is defined.
* Document about `VIRTUALENVWRAPPER_PYTHON` and `VIRTUALENVWRAPPER_VIRTUALENV`
(this would be particularly important in macOS after recent homebrew update)
* Add additional documentation for `initialize` in _README.md_ and _zpreztorc_
* Add aliases `py2`, `py3` as shortcut for `python2`, `python3` respectively
We cannot always assume availability of `pip`, it can be `pip2` or `pip3`
instead. We detect the first available one and use it for generating the
completion cache.
* Command to activate virtualenvs on changing directory
Enables automatic activation of a virtualenv when jumping into a directory
This is done by looking in the current directory for a file or directory
named `.venv`. If it's not found in the current directory its parents will
also be examined. `.venv` can be either:
1. A file containing the name of a virtualenv found in $WORKON_HOME
2. A directory containing bin/activate (meaning that the directory is
assumed to be a virtualenv.)
If $WORKON_HOME is set it is assumed that virtualenvwrapper is installed
and the `workon` command will be issued.
This shouldn't cause problems for anyone and should improve startup times for
anyone using python with virtualenvwrapper because it will wait for the first
command to load rather than right away.
* Support skip-virtualenvwrapper-init zstyle in python module to avoid auto-sourcing of virtualenvwrapper.sh
* Don't overwrite the WORKON_HOME env var if the user has already set it
Indrajit Raychaudhuri