Better, what does

<that interpreter> -s -c 'import sys, os; print(os.linesep.join(sys.path))'

say?

This is strange and I'd love to get to the bottom of it. For full context, the interpreter identification code runs with -s to exclude user site-packages but can't run with -S to exclude site-packages since this is broken under many distributions. Instead of -S, Pex extracts itself to a chroot and exports that chroot as PYTHONPATH for the interpreter identification run. That inserts the extracted Pex chroot at the head of sys.path and so should isolate interpreter identification from any system installed Pex.

The PYTHONPATH trick does leave

.

1st on

sys.path

so, afaict, the only way to get older Pex being used is to have the Pex repo checked out on an old version at

.

or something similar. I've certainly been continually surprised though.

The sys.path (with -s) is

/Users/benjyw/.pyenv/versions/3.7.3/lib/python37.zip
/Users/benjyw/.pyenv/versions/3.7.3/lib/python3.7
/Users/benjyw/.pyenv/versions/3.7.3/lib/python3.7/lib-dynload
/Users/benjyw/.pyenv/versions/3.7.3/lib/python3.7/site-packages

Oh, hm, but the problem persists even after I uninstall pex from the site-packages

I verified that pex is not installed on any interpreter on my machine's site-packages

And I deleted my source checkout of the pex repo , to be sure that's not somehow on the PYTHONPATH

Plus that is at a much later version, one which has that

binary=

argument.

The leak of

.

onto the

sys.path

during interpreter identification is reproed and tracked here: https://github.com/pantsbuild/pex/issues/1231 That said, I don't think that can be the mechanism here since $PWD is the Pants process execution chroot and that chroot does not have an old Pex installed anywhere in it.

And after help from Benjy reproing and isolating all this, the real bug is here: https://github.com/pantsbuild/pex/issues/1232 This has been a bug for a year and a few days and only affects users of the Pex PEX Pex releases via Github Releases (e.g.: Pants). PyPI users would be unaffected. Fixes for this issue and the theoretical

.

leak issue coming up in a Pex 2.1.31 release.