-
-
Notifications
You must be signed in to change notification settings - Fork 531
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix provisioning from pyvenv interpreter #1452
Fix provisioning from pyvenv interpreter #1452
Conversation
19d6e1c
to
4f1743a
Compare
When the original interpreter [0] tox is called with is actually a pyvenv it will set the `__PYVENV_LAUNCHER__` environment variable to the path of pyvenv interpreter. If tox configuration specifies `requires` and the requirements are not satifsfied by [0], tox will create an intermediate virtual environment [1]. After setting up [1] tox will delegate the original call by spawning a new [1] interpreter with the identical identical list of arguments. It will also pass the value of `__PYVENV_LAUNCHER__` if present. This in turn causes `sys.executable` to resolve to [0] instead of [1] therefore ignoring all modifications including installed requirements. The fix is to make sure that when [0] spawns [1], `__PYVENV_LAUNCHER__` is removed from the environment.
4f1743a
to
40f4860
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lg2m, pre-commit has the same code: https://github.com/pre-commit/pre-commit/blob/0fd4a2ea38df4f276e43397e21ecb3fcbc96d122/pre_commit/main.py#L32-L36
shakesfist framework builds
@Kentzo could you fix the tests so this can be merged? thanks! |
@asottile Are you sure the failure is related to the change? I may take a look, but I'm completely unfamiliar with the codebase. |
I don't think the ci failure is related, but let's not merge until we fix master and rebase. Thanks! |
This now has been released under https://tox.readthedocs.io/en/latest/changelog.html#v3-14-1-2019-11-13 |
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)