Looking at `src/python/pants/backend/python/util_r...
# development
b
Looking at
src/python/pants/backend/python/util_rules/pex.py
, and specifically the usages of
PexCliProcess
and the Python it is run with. ๐Ÿงต
build_pex
is the only usage of a user Python running the Pex CLI process. Is this really necessary? Would it change the behavior of building a PEX to unconditionally use (some) Python which isn't the Python we run user code with?
e
Pex will use the Python it is run with to build PEX files if the Python it is run with meets ICs. If the PEX build requires any native sdist builds, the Python better be able to handle that.
That is the only restriction.
b
Bummer. Any way to disable that behavior and treat the running Python as some foreign thing? As if Pex was written in FORTRAN and
sys.executable
is the FORTRAN interpreter? (obviously a thought experiment)
e
Yes, there is. Do you want me to feed you that or do you want to read more 1st?
b
I assume its somewhere in https://pex.readthedocs.io/en or
--help
?
e
You could figure it out just from Pants code if you paged the util rules code in. But ...
I find this frustrating. This is what
PEX_PYTHON_PATH
/
--python-path
is for.
b
Ah yeah I would'nt have pieced that together ๐Ÿ˜•
e
You definitely should have been able to.
b
I don't see the behavior of using the running Python when building a pex anywhere in
--help
looking specifically at the
PEX target environment options:
section, so I don't feel too bad ๐Ÿ™‚
e
Like I said, it's right in the Pants source code.
You were incurious about existing util rules grokking.
b
Unless its
The Python interpreter to use (default: current interpreter)
, in which case yay I found it, but not how to change it in the absense of an absolute path
I also find the existing pex rule code extremely hard to grok. Likely a result of the complexity of the ecosystem
e
Agreed! But I'm frustrated that you outsource the grokking. It's complicated but nowhere near impossible and when you grok a thing, you really know it. It's a good bit of pain to go through.
b
Looks like
--python-path
is unconditionally passed (because the controlling variable is never
False
) so I'll pin this with a comment and switch the pex invocation to use some mystical Python