Previously the Pex venv code would blow up when it encountered a venv
with multiple distinct site-packages directories. Although this was
safe, it was unhelpful for virtualenvs created by modern Virtualenv on
Red Hat based distributions where there is a separation between
purelib (lib/pythonX.Y/site-packages) and
platlib (lib64/pythonX.Y/site-packages). Interestingly this was not a
problem for Python stdlib -mvenv virtualenvs since those create the
lib64/ platlib directory as a symlink to the lib/ purelib
directory. It's unclear who is constructing venvs correctly here, but
given the Virtualenv layout, its definitely correct to honor the
purelib / platlib distinction when installing wheels in venvs. Pex now
does this and tests are added to confirm.
Also fix up various existing tests that failed on ARM machines where
this problem was discovered.
Previously the Pex venv code would blow up when it encountered a venv with multiple distinct site-packages directories. Although this was safe, it was unhelpful for virtualenvs created by modern Virtualenv on Red Hat based distributions where there is a separation between purelib (
lib/pythonX.Y/site-packages) and platlib (lib64/pythonX.Y/site-packages). Interestingly this was not a problem for Python stdlib-mvenvvirtualenvs since those create thelib64/platlib directory as a symlink to thelib/purelib directory. It's unclear who is constructing venvs correctly here, but given the Virtualenv layout, its definitely correct to honor the purelib / platlib distinction when installing wheels in venvs. Pex now does this and tests are added to confirm.Also fix up various existing tests that failed on ARM machines where this problem was discovered.