Skip to content
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

Fixup pex re-exec during bootstrap. #741

Merged
merged 5 commits into from
Jun 25, 2019
Merged

Conversation

jsirois
Copy link
Member

@jsirois jsirois commented Jun 24, 2019

Ensure PEX_PYTHON and PEX_PYTHON_PATH are actually scrubbed from the
environment of the pex process when re-exec'd fixing #710. Also
uniformize re-exec interpreter selection to ensure that the current
interpreter is preferred when it meets any constraints fixing #709.

Fixes #709
Fixes #710

@jsirois
Copy link
Member Author

jsirois commented Jun 24, 2019

NB: Integration tests are forthcoming, but the production code changes are reviewable.

@jsirois
Copy link
Member Author

jsirois commented Jun 24, 2019

Now fully reviewable.

pex/pex_bootstrapper.py Outdated Show resolved Hide resolved
@jsirois jsirois mentioned this pull request Jun 24, 2019
6 tasks
tests/test_integration.py Outdated Show resolved Hide resolved
[sys.executable, test_pex, '-c', 'import json, os; print(json.dumps(os.environ.copy()))'],
env=env
)
final_env = json.loads(output.decode('utf-8'))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clever way to test this. Good idea.

tests/test_integration.py Outdated Show resolved Hide resolved
pex/pex_bootstrapper.py Outdated Show resolved Hide resolved
pex/pex_bootstrapper.py Outdated Show resolved Hide resolved
pex/pex_bootstrapper.py Outdated Show resolved Hide resolved
pex/pex_bootstrapper.py Outdated Show resolved Hide resolved
@@ -75,9 +75,6 @@ def __init__(self, environ=None, rc=None, use_defaults=True):
def copy(self):
return self._environ.copy()

def delete(self, variable):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

pex/pex_bootstrapper.py Outdated Show resolved Hide resolved
Ensure `PEX_PYTHON` and `PEX_PYTHON_PATH` are actually scrubbed from the
environment of the pex process when re-exec'd fixing pex-tool#710. Also
uniformize re-exec interpreter selection to ensure that the current
interpreter is preferred when it meets any constraints fixing pex-tool#709.

Fixes pex-tool#709
Fixes pex-tool#710
Use explicit return, pass narrower types and improve docs & logging.
@@ -116,12 +116,12 @@ def maybe_reexec_pex(compatibility_constraints=None):

current_interpreter = PythonInterpreter.get()

# NB: Used only for debugging and tests.
pex_exec_chain = []
# NB: Used only for tests.
if '_PEX_EXEC_CHAIN' in os.environ:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel slightly less dirty with this tweak. Now user code will never see _PEX_EXEC_CHAIN in the environment in production.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this used somehow before? Confused about the "now" verbage.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before 4efafc2 the _PEX_EXEC_CHAIN environment variable always leaked to the environment of user code - they could see it and read it. Now (with the fix in 4efafc2), the environment variable is never exposed by the pex runtime. It must 1st be present in the enviornment to be mutated. IE: Only if you run _PEX_EXEC_CHAIN=1 ./my.pex will the variable be mutated to populate it with the interpreter invocation chain. Tests do this, users won't know to do this.

# We've already been here and selected an interpreter. Continue to execution.
return

target = None
with TRACER.timed('Selecting runtime interpreter based on pexrc', V=3):
with TRACER.timed('Selecting runtime interpreter', V=3):
if ENV.PEX_PYTHON and not ENV.PEX_PYTHON_PATH:
# preserve PEX_PYTHON re-exec for backwards compatibility
# TODO: Kill this off completely in favor of PEX_PYTHON_PATH
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This something that should probably happen soon. Not sure if we have a deprecation policy around this but it is redundant with PPP and more complexity to support than necessary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the bit needed to kick off deprecation / removal is expanding "it's redundant" in an issue. FWICT it is not simply redundant. Today I can PEX_PYTHON=python2 ... to ensure a pex runs under some python2 interpreter on any machine. I can't do that with PEX_PYTHON_PATH since its entries are full paths or path prefixes, both of which are machine specific.

Handle environment overrides for the Python interpreter to use when executing this pex.

def maybe_reexec_pex(compatibility_constraints=None):
"""Handle environment overrides for the Python interpreter to use when executing this pex.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a style change or does it change any presentations from help/pydocs, etc? Just curious.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a style change - I wanted to make it clear None was an acceptable input. The general implication of def maybe_reexec_pex(compatibility_constraints) is that compatibility_constraints are required.

Copy link
Contributor

@CMLivingston CMLivingston left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I've manually verified our usage patterns at Twitter and where we were planning to leverage the new behavior. Thanks for taking care of this and for introducing the new test cases!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants