virtualenvwrapper stopped working #1413
Comments
|
Thanks for the tip @indrajitr . I thought on how to improve that section, but couldn't find an easy and elegant solution (that does not involve just reverting the changes on the section). |
diraol
pushed a commit
to diraol/prezto
that referenced
this issue
Aug 4, 2017
Currently if one have pyenv but not pyenv-virtualenv the virtualenvwrapper is never loaded. If no pyenv-virtualenvwrapper is present, then try to load the default python virtualenvwrapper tool. Fix sorin-ionescu#1413
|
Thanks @indrajitr , I've just commented over there. =) |
This was referenced Oct 26, 2022
jeffwidman
added a commit
that referenced
this issue
Oct 26, 2022
The desired logic is: If `virtualenv-init` plugin for `pyenv` present, activate it If `virtualenvwrapper` plugin for `pyenv` present, activate it If neither plugin is present, then fallback to normal virtualenvwrapper. Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by #1981 which solved for when the `pyenv` `virtualenvwrapper` plugin was present but not the `virtualenv-init` plugin. Since the presence of either plugin indicates we should skip the fallback, this switches to using a flag variable if either plugin is found. Additionaly, as an optimization, the check for the `pyenv` plugins are skipped if `pyenv` itself isn't found. Looking at `git blame`, there's a _lot_ of prior art here around trying to support all the permutations of `pyenv` and various plugins: * #1413 * #1414 * #1433 * #1434 So we need to be extremely careful to continue to support all these permutations.
jeffwidman
added a commit
that referenced
this issue
Oct 26, 2022
…or `virtualenvwrapper` plugins The desired logic is: If `virtualenv-init` plugin for `pyenv` present, activate it If `virtualenvwrapper` plugin for `pyenv` present, activate it If neither plugin is present, then fallback to normal virtualenvwrapper. Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by #1981 which solved for when the `pyenv` `virtualenvwrapper` plugin was present but not the `virtualenv-init` plugin. Since the presence of either plugin indicates we should skip the fallback, this switches to using a flag variable if either plugin is found. Additionaly, as an optimization, the check for the `pyenv` plugins are skipped if `pyenv` itself isn't found. Looking at `git blame`, there's a _lot_ of prior art here around trying to support all the permutations of `pyenv` and various plugins: * #1413 * #1414 * #1433 * #1434 So we need to be extremely careful to continue to support all these permutations.
jeffwidman
added a commit
that referenced
this issue
Oct 26, 2022
…or `virtualenvwrapper` plugins 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`](#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by #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: * #1413 * #1414 * #1433 * #1434 So we need to be extremely careful to continue to support all these permutations.
jeffwidman
added a commit
that referenced
this issue
Oct 26, 2022
…or `virtualenvwrapper` plugins 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`](#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by #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: * #1413 * #1414 * #1433 * #1434 So we need to be extremely careful to continue to support all these permutations. Fix #2022
jeffwidman
added a commit
that referenced
this issue
Oct 26, 2022
…or `virtualenvwrapper` plugins 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`](#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by #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: * #1413 * #1414 * #1433 * #1434 So we need to be extremely careful to continue to support all these permutations. Fix #2022
jeffwidman
added a commit
that referenced
this issue
Oct 26, 2022
…or `virtualenvwrapper` plugins 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`](#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by #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: * #1413 * #1414 * #1433 * #1434 So we need to be extremely careful to continue to support all these permutations. Fix #2022
jeffwidman
added a commit
that referenced
this issue
Oct 26, 2022
…or `virtualenvwrapper` plugins 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`](#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by #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: * #1413 * #1414 * #1433 * #1434 So we need to be extremely careful to continue to support all these permutations. Fix #2022
jeffwidman
added a commit
that referenced
this issue
Oct 27, 2022
…or `virtualenvwrapper` plugins 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`](#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by #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: * #1413 * #1414 * #1433 * #1434 So we need to be extremely careful to continue to support all these permutations. Fix #2022
johnoshea
pushed a commit
to johnoshea/prezto
that referenced
this issue
Oct 29, 2022
…or `virtualenvwrapper` plugins 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`](sorin-ionescu#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](sorin-ionescu#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by sorin-ionescu#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: * sorin-ionescu#1413 * sorin-ionescu#1414 * sorin-ionescu#1433 * sorin-ionescu#1434 So we need to be extremely careful to continue to support all these permutations. Fix sorin-ionescu#2022
dokai
pushed a commit
to dokai/prezto
that referenced
this issue
Nov 29, 2022
…or `virtualenvwrapper` plugins 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`](sorin-ionescu#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](sorin-ionescu#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by sorin-ionescu#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: * sorin-ionescu#1413 * sorin-ionescu#1414 * sorin-ionescu#1433 * sorin-ionescu#1434 So we need to be extremely careful to continue to support all these permutations. Fix sorin-ionescu#2022
MohamedBassem
pushed a commit
to MohamedBassem/prezto
that referenced
this issue
Mar 11, 2023
…or `virtualenvwrapper` plugins 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`](sorin-ionescu#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](sorin-ionescu#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by sorin-ionescu#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: * sorin-ionescu#1413 * sorin-ionescu#1414 * sorin-ionescu#1433 * sorin-ionescu#1434 So we need to be extremely careful to continue to support all these permutations. Fix sorin-ionescu#2022
get-state
pushed a commit
to get-state/prezto
that referenced
this issue
Apr 2, 2023
…or `virtualenvwrapper` plugins 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`](sorin-ionescu#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](sorin-ionescu#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by sorin-ionescu#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: * sorin-ionescu#1413 * sorin-ionescu#1414 * sorin-ionescu#1433 * sorin-ionescu#1434 So we need to be extremely careful to continue to support all these permutations. Fix sorin-ionescu#2022
MattHodge
pushed a commit
to MattHodge/prezto
that referenced
this issue
Jun 17, 2023
…or `virtualenvwrapper` plugins 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`](sorin-ionescu#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](sorin-ionescu#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by sorin-ionescu#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: * sorin-ionescu#1413 * sorin-ionescu#1414 * sorin-ionescu#1433 * sorin-ionescu#1434 So we need to be extremely careful to continue to support all these permutations. Fix sorin-ionescu#2022
dandrzejewski
pushed a commit
to dandrzejewski/prezto
that referenced
this issue
Aug 23, 2023
…or `virtualenvwrapper` plugins 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`](sorin-ionescu#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](sorin-ionescu#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by sorin-ionescu#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: * sorin-ionescu#1413 * sorin-ionescu#1414 * sorin-ionescu#1433 * sorin-ionescu#1434 So we need to be extremely careful to continue to support all these permutations. Fix sorin-ionescu#2022
tjmcs
pushed a commit
to tjmcs/prezto
that referenced
this issue
Sep 1, 2023
…or `virtualenvwrapper` plugins 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`](sorin-ionescu#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](sorin-ionescu#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by sorin-ionescu#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: * sorin-ionescu#1413 * sorin-ionescu#1414 * sorin-ionescu#1433 * sorin-ionescu#1434 So we need to be extremely careful to continue to support all these permutations. Fix sorin-ionescu#2022
glebec
pushed a commit
to glebec/prezto
that referenced
this issue
Oct 8, 2023
…or `virtualenvwrapper` plugins 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`](sorin-ionescu#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](sorin-ionescu#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by sorin-ionescu#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: * sorin-ionescu#1413 * sorin-ionescu#1414 * sorin-ionescu#1433 * sorin-ionescu#1434 So we need to be extremely careful to continue to support all these permutations. Fix sorin-ionescu#2022
danyi-david
pushed a commit
to danyi-david/prezto
that referenced
this issue
May 23, 2024
…or `virtualenvwrapper` plugins 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`](sorin-ionescu#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](sorin-ionescu#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by sorin-ionescu#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: * sorin-ionescu#1413 * sorin-ionescu#1414 * sorin-ionescu#1433 * sorin-ionescu#1434 So we need to be extremely careful to continue to support all these permutations. Fix sorin-ionescu#2022
tjmcs
pushed a commit
to tjmcs/prezto
that referenced
this issue
Jun 12, 2024
…or `virtualenvwrapper` plugins 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`](sorin-ionescu#1414 (comment)). 3. If `virtualenvwrapper` plugin is present, then [don't fallback to standard `virtualenvwrapper`, regardless of whether `virtualenv-init` is present](sorin-ionescu#1981 (comment)). Previously, if the `virtualenv` command was present but `pyenv` was missing, then the fallback wouldn't be hit. This bug was introduced by sorin-ionescu#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: * sorin-ionescu#1413 * sorin-ionescu#1414 * sorin-ionescu#1433 * sorin-ionescu#1434 So we need to be extremely careful to continue to support all these permutations. Fix sorin-ionescu#2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Until last week (aprox.) my virtualenvwrapper module was working just fine, zpresto was sourcing it without any problems. But, I've made an update yesterday that made it stop working. As far as I could understand, it is not being sourced/loaded, despite
virtualenvbeing available (this is the pre-requisite).If I can provide any other information I'm fully available to do it, and I would appreciate any help in order to debug this problem. =)
Thanks in advance!
Expected behavior
Have the (python) virtualenvwrapper utilities available on the shell.
Actual behavior
Virtualenvwrapper was not sourced on shell load, thus its aliases and utilities are not available at the shell.
Versions
And my runcoms mods:
zshenv:
zprofile:
zprestorc
The text was updated successfully, but these errors were encountered: