https://pantsbuild.org/ logo
Powered by
#pex
Title
h

happy-kitchen-89482

02/13/2021, 8:41 PM
And similar errors with 
./pants test tests/python/pants_test/init/test_plugin_resolver.py
e

enough-analyst-54434

02/13/2021, 9:03 PM
Can you provide any more data on that .pyenv interpreter? What does it have installed in it's site-packages for example.
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.
h

happy-kitchen-89482

02/14/2021, 5:32 AM
OK so confirmed that the interpreter has pex 2.1.12 in its site-packages
The sys.path (with -s) is
Copy code
/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.
e

enough-analyst-54434

02/14/2021, 4:54 PM
If you could run with 
--no-process-execution-cleanup-local-dirs
it would be useful to be able to inspect the chroot.
h

happy-kitchen-89482

02/15/2021, 1:09 AM
DM'd it to you
e

enough-analyst-54434

02/15/2021, 5:31 PM
2.1.17 was the 1st version to get 
get(binary=...)
; so your 2.1.12 in site-packages bit above is still a lead.
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.
Powered by