you'd have to pass `--inherit-sitepackages`?
# pex
w
you'd have to pass
--inherit-sitepackages
?
e
That's correct. You'd have to pass
--inherit-path=(fallback|prefer)
when building the pex to get it to not scrub sys.path. You can observe scrubbing (or lack thereof) by running the pex with
PEX_VERBOSE=9
. You can also sanity check the pex with
unzip -qc <pex file> PEX-INFO | jq .inherit_path
. At runtime there is the
PEX_INHERIT_PATH
env var / slurping that from .pexrc. Perhaps you are being bit by the last.
w
Ok, thanks! Will look into that Monday.
@enough-analyst-54434: mmm:
Copy code
pex: Not a tainted path element: /Users/example/.venvburrito/lib/python2.7/site-packages
pex: Not a tainted path element: /Users/example/.venvburrito/lib/python2.7/site-packages/setuptools-28.8.0-py2.7.egg
pex: Not a tainted path element: /Users/example/.venvburrito/lib/python2.7/site-packages/pip-9.0.1-py2.7.egg
the
venvburrito
entry caused a few users some issues
e
pex: Not a tainted path element: .../site-packages
implies PEX_INHERIT_PATH. That is the crucial investigatory bit to suss. If set in PEX-INFO, env or via .pexrc that is the issue and it's of the foisted on petard variety. If not, it's a pex
sys.path
scrubbing bug.
w
Copy code
$ unzip -qc  ~/.cache/pants/pex/bin/pants.pex/1.15.0rc0-git5c01b701/pants.pex PEX-INFO | jq .inherit_path
"false"
e
Ok, not surprising. .pexrc though is the Twitter issue generally. Conclusions on that?
w
these users have no
PEX
-related env... i'll double check that we're not setting it anywhere
~/.pexrc
sets
PEX_PYTHON_PATH
and
PEX_PYTHON
, but not inherit
...nothing setting
PEX_INHERIT_PATH
...would more of the PEX_VERBOSE output help?
e
A straight up issue would be amazing.
w
yea. alrighty.
e
I can give you debug steps there that will involve unzipping, editing a file, etc.
w
e
Excellent - thank you.