After profiling startup time, I found that "pyenv rehash" is
by far the slowest piece. This change skips rehashing on init.
See https://github.com/pyenv/pyenv/issues/784#issuecomment-404850327
Also pass the shell explicitly, as suggested in
https://github.com/pyenv/pyenv/issues/784#issuecomment-404944318,
which provides a modest improvement.
In total, this improves startup time from 1s to 0.3s on my machine.
Using the following command:
python -m timeit "__import__('subprocess').Popen(['zsh', '-i', '-c', 'echo']).communicate()"
Result before this change:
10 loops, best of 3: 1 sec per loop
Result after this change:
10 loops, best of 3: 334 msec per loop
* Added conda virtualenv support to python module
* Added instructions for Python module options to README
Thanks to @egpbos for the original feature and @ickc for fixing the merge conflicts.
Now that pyenv plugins availability is detected by directly probing
'pyenv', we need to rely on the same mechanism consistently.
Further, we perform available pyenv plugin scan with native zsh
techniques instead of relying on external commands.
If the pyenv virtualenv plugin is installed using the [pyenv-installer][1]
app script or directly via a [Git clone][2], then the pyenv-virtualenv-init
executable, that the `pyenv virtualenv-init` command uses, will not
exist in the user's PATH and therefore cannot be found using
`$commands[pyenv-virtualenv-init]`.
Installing the pyenv-virtualenv plugin in this manner is common among Linux users.
Using the pyenv `commands` command, which lists all commands pyenv can
run, we can find if the virtualenv-init command is available to pyenv
and subsequently the virtualenv plugin, without relying on
pyenv-virtualenv-init to exist in the user's PATH.
[1]: https://github.com/pyenv/pyenv-installer
[2]: https://github.com/pyenv/pyenv-virtualenv#installing-as-a-pyenv-plugin
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
Kaleb Elwert