Although it has tags, the release flow it is not well estabilished,
so it fall behind quite recurrently, thus why I'm updating it aginst the
master branch (it was already out of the latest tag anyway).
Ref:
https://github.com/zsh-users/zsh-completions/issues/1083
Adjust instruction for setting custom `$ZDOTDIR`.
This addresses 2 potential issues:
- Check for the presence of `$XDG_CONFIG_HOME/zsh` before assigning it to `$ZDOTDIR` instead of blindly assigning
- Avoid recursion in zsh variable assignment stack that might occasionally result in messages like:
```
zsh: job table full or recursion limit exceeded
```
The startup logic and instructions have been updated for simplicity in
pyenv 2.3.0. The workaround for pyenv init is no longer necessary.
Signed-off-by: Indrajit Raychaudhuri <irc@indrajit.com>
The desired logic is:
For the `pyenv` plugins `virtualenv-init` and `virtualenvwrapper`:
1. If either plugin is present, activate it
2. If `virtualenvwrapper` plugin is not present, then
[fallback to standard
`virtualenvwrapper`](https://github.com/sorin-ionescu/prezto/pull/1414#issuecomment-320306421).
3. If `virtualenvwrapper` plugin is present, then [don't fallback to
standard `virtualenvwrapper`, regardless of whether `virtualenv-init`
is
present](https://github.com/sorin-ionescu/prezto/pull/1981#issue-1123766676).
Previously, if the `virtualenv` command was present but `pyenv` was
missing, then the fallback wouldn't be hit. This bug was introduced by
https://github.com/sorin-ionescu/prezto/pull/1981/ which ensured that
the `pyenv` `virtualenvwrapper` plugin was activated if present,
regardless of the presence of the `virtualenv-init` plugin.
As an optimization, the check for the `pyenv` plugins are skipped if
`pyenv` itself isn't found.
Since we only want to fallback if the `pyenv` `virtualenvwrapper` plugin
is missing, but that's buried within the `pyenv` logic and we also need
to handle when `pyenv` itself is missing, this switches to using a flag
variable.
I also renamed the `virtualenv_sources` var to
`virtualenvwrapper_sources` as `virtualenv` is distinct from
`virtualenvwrapper`, so using one name for a var that is really about
the other is confusing.
Looking at `git blame`, there's a _lot_ of prior art here around trying
to support all the permutations of `pyenv` and various plugins:
* https://github.com/sorin-ionescu/prezto/issues/1413
* https://github.com/sorin-ionescu/prezto/pull/1414
* https://github.com/sorin-ionescu/prezto/pull/1433
* https://github.com/sorin-ionescu/prezto/pull/1434
So we need to be extremely careful to continue to support all these
permutations.
Fix https://github.com/sorin-ionescu/prezto/issues/2022
This is needed to find python.
It is often already set because a user has the directory or completion module loaded before this, but that's not always true.
See extensive debugging / further explanation here: https://github.com/sorin-ionescu/prezto/issues/1949
This does not fully resolve that issue, as there's another enhancement that I'll put up as a separate PR.
In most systems, python2 or python3 command/soft-link would almost
always exist. In such cases, we don't need to invoke `python` to
detect the version. This should speed things up a bit as well.
