Closed jeffwidman closed 1 year ago
@zbirenbaum @diraol @zachwhaley since you were all involved in prior PR's around this section of code logic, can you take this for a test drive to ensure I'm not accidentally breaking something in your use cases with this.
Also @indrajitr / @belak I'd appreciate some sanity check reviews.
I like this too. My change was a quick one to prevent people from getting locked out of their systems since that’s a really bad bug to have. This is a better formalization.
Thanks all!
I'm going to merge given the positive reception. If we find further bugs/unhandled edge cases, I'm happy to take another look.
The desired logic is:
For the
pyenv
pluginsvirtualenv-init
andvirtualenvwrapper
:virtualenvwrapper
plugin is not present, then fallback to standardvirtualenvwrapper
.virtualenvwrapper
plugin is present, then don't fallback to standardvirtualenvwrapper
, regardless of whethervirtualenv-init
is present.Previously, if the
virtualenv
command was present butpyenv
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 thepyenv
virtualenvwrapper
plugin was activated if present, regardless of the presence of thevirtualenv-init
plugin.As an optimization, the check for the
pyenv
plugins are skipped ifpyenv
itself isn't found.Since we only want to fallback if the
pyenv
virtualenvwrapper
plugin is missing, but that's buried within thepyenv
logic and we also need to handle whenpyenv
itself is missing, this switches to using a flag variable.I also renamed the
virtualenv_sources
var tovirtualenvwrapper_sources
asvirtualenv
is distinct fromvirtualenvwrapper
, 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 ofpyenv
and various plugins:So we need to be extremely careful to continue to support all these permutations.
Fix https://github.com/sorin-ionescu/prezto/issues/2022