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/2022pull/2029/head
parent
ca9012c776
commit
e3a9583f33
Loading…
Reference in new issue