Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Release more flexible pex binaries. #654
Currently we release pex27 and pex37. Since pex is dependency free and supports both python 2.7 and python 3.4-3.7, we would ideally release one binary that could run under all these interpreters.
Typical systems will have on the PATH:
The current release process creates binaries with shebangs from the fourth category which has the upshot of not providing a binary for pythons 3.4, 3.5 or 3.6 even though both the pex27 and pex37 could otherwise run under these pythons.
We should release binaries to support 3.4, 3.5 and 3.6 either by releasing one binary that uses a shebang with
For idea one, passing multiple
For idea one and two,
I've gone ahead and brute-forced for the 1.6.1 release by including
I'll leave this issue open until I break out
referenced this issue
Jan 25, 2019
This was referenced
Jan 25, 2019
This was intended. The confusion and issues we are seeing that stem from OR vs AND are largely due to my ignorance of pex use cases (I was relatively new to the codebase when I made these changes), and I was having difficulty trying to understand why anyone would OR at all within the context of the change I was making at the time, which was to move from a single PEX_PYTHON (use this interpreter) -> PEX_PYTHON_PATH (use one of these based on constraints of the binary). That was the use case I was targeting with
Long story short, it was intended for the use case and I was confused at the time / thought that ORing constraints was a bug, so I added that option in to be more explicit and give finer grain control. Ultimately, I think the custom nature of PPP and PP is different from what you are describing here because it is much more pointed, custom setting regarding which interpreter to use vs. giving the freedom and flexibility to encompass a wide range (this being largely because it grew out of the singular PEX_PYTHON). By design, PPP-based selection will not fall back to $PATH, and will error out if the AND is not satisfied. Admittedly, this was heavily influenced by monorepo philosophy / pants, where we were trying to go from one canonical interpreter to two, feature-incompatible canonical interpreters.
I think one possible solution here would be to fragment the call to