Pants 2.7.1 is building my

.pex

with the shebang

#!/usr/bin/env python3.8

despite my pants.toml telling it to use python3.9

[python-setup]
interpreter_constraints = ["CPython==3.9.*"]

And the platforms being set to 3.9

pex_binary(
    name="server",
    platforms=["linux_x86_64-cp-39-cp39", "macosx_11.0_x86_64-cp-39-cp39"],
    entry_point="some_project/server.py:main"
)

The same happens if I set the bex_binary's

interpreter_constraints

directly

I'm not sure why the shebang is defaulting to that value, but you can always specify it directly with the

shebang

field on `pex_binary`: https://www.pantsbuild.org/docs/reference-pex_binary

Yeah this is what I ended up doing... But I'd like it if while educating my colleagues on Pants I didn't have to explain this away as a weirdness or bug I've had to work around (which it probably isn't). Doing this properly will definitely help me push this forward as a good solution to our problems.

Ok. Well, if viewed as a bug, it's a bug in Pex. Pex uses a shebang of

#!/usr/bin/env pythonX.Y

where

X.Y

is taken from the interpreter used to execute the Pex CLI in this case of a pure

--platform

PEX. So Pants is running Pex with python 3.8 (probably because that's the Python Pants itself is running with - which need no match your code's interpreter constraints at all). For PEXes that use only `--platform`like yours, any interpreter will do when running the Pex CLI since

--platform

is shorthand for "Build this PEX file for this - foreign - platform. I.E.: Only fetch pre-built wheels, never try to build sdists into wheels.". It might make sense for Pex to treat the pure

--platform

case specially, and iff all platforms in the list share the same Python major / minor version, use that for the X.Y in the shebang. Generally, though, multiplatform PEXes can span many major minors, say >=3.7,<3.10. In that general case Pex cannot pick a shebang that will always work. For example,

#!/usr/bin/env python

, which would be one obvious choice, might pick Python 2.7 on one machine, and that would be incorrect. So mayube

#!/usr/bin/env python3

? Same problem, might pick Python 3.6. Even weirder - on some distros, the

python3

version of the - say - Python 3.7 binary, might not be installed at all. Although it's typical to have

python

,

pythonX

and

pythonX.Y

its not done by all distributions.

Thanks for that explanation John 👍