Fix provisioning from pyvenv interpreter #1452
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
The bug is related to #148.
When the original interpreter [0] tox is called with is actually a pyvenv
it will set the
__PYVENV_LAUNCHER__
environment variable the path of pyvenvinterpreter.
If tox configuration specifies
requires
and the requirements are notsatifsfied by [0], tox will create an intermediate virtual environment [1].
After setting up [1] tox will delegate the original call to it by spawning
a new [1] interpreter with the list of arguments identical to [0].
It would also pass the value of
__PYVENV_LAUNCHER__
if present. This in turncauses
sys.executable
to resolve to [0] instead of [1] therefore ignoring allmodifications including installed requirements.
The fix is to make sure that when [0] spawns [1],
__PYVENV_LAUNCHER__
is removedfrom the environment.
Contribution checklist:
(also see CONTRIBUTING.rst for details)
in message body
<issue number>.<type>.rst
for example (588.bugfix.rst)<type>
is must be one ofbugfix
,feature
,deprecation
,breaking
,doc
,misc
<your username>
"superuser
."CONTRIBUTORS
(preserving alphabetical order)