If I inspect <pants.2.19.0-cp39-linux_x86_64.pex> ...
# general
s
If I inspect pants.2.19.0-cp39-linux_x86_64.pex I see it was created with
{"pex_version": "2.1.148"}
. Is there a reason a newer version of Pex isn't used? I'd love to get the shebang max length fix from https://github.com/pantsbuild/pex/pull/2295 which I think was released in
2.1.154
I suppose I just need to wait https://github.com/pantsbuild/pants/pull/20416. Is it possible to "backport" this change into 2.19.0?
c
You can use it earlier, just update your
pants.toml
config according to this example (need to get new values though) https://pantsbuild.slack.com/archives/C01SPQQ2WK1/p1658781480175079?thread_ts=1655657786.208049&amp;cid=C01SPQQ2WK1
s
I've updated my pants.toml to use PEX 2.1.161. Unfortunately this doesn't seem to impact the Pants PEX itself (i.e. xdg_cache_home/nce/.../bin/pants). My understanding is this will only change the version of PEXs for PEXs built by pants. When scie-pants bootstraps pants it downloads the pre-baked pants PEX from the GitHub release page. I think the released Pants PEX would have to change.
Fwiw I updated the PEX CLI because I thought it would fix the "exec format error" coworkers were getting when running just "pants" (no goals, just pants). Unfortunately, coworkers have been reporting that they still run into this problem even after merging in that fix and clearing their cache. I experienced another more fun version of this bug where the -sE was getting cutoff and so it still "worked" but it leaked my pythonpath env variable into sys.argv making pantsd invalidate on every file change.