Releases: pex-tool/pex
pex 2.14.0
2.14.0
This release brings support for creating PEX scies for PEXes targeting
PyPy. In addition, for PEX scies targeting CPython, you can now
specify --scie-pbs-stripped to select a stripped version of the
Python Standalone Builds CPython distribution embedded in your
scie to save transfer bandwidth and disk space at the cost of losing
Python debug symbols.
Finally, support is added for --scie-busybox to turn your PEX into a
multi-entrypoint BusyBox-like scie. This support is
documented in depth at https://docs.pex-tool.org/scie.html
pex 2.13.1
2.13.1
This release fixes the --scie option to support building a Pex PEX
scie with something like pex pex -c pex --venv --scie eager -o pex.
Previously, due to the output filename of pex colliding with fixed
internal scie lift manifest file names, this would fail.
- Handle all output file names when building scies. (#2484)
pex 2.13.0
2.13.0
This release improves error message detail when there are failures in
Pex sub-processes. In particular, errors that occur in pip download
when building a PEX or creating a lock file now give more clear
indication of what went wrong.
Additionally, this release adds support for --pip-version 24.2.
pex 2.12.1
2.12.1
This release refreshes the root CA cert bundle used by
--pip-version vendored (which is the default Pip Pex uses for
Python <3.12) from certifi 2019.9.11's cacert.pem to
certifi 2024.7.4's
cacert.pem. This refresh addresses at least CVE-2023-37920 and was spearheaded by
a contribution from Nash Kaminski in
pex-tool/pip#12. Thank you, Nash!
- Update vendored Pip's CA cert bundle. (#2476)
pex 2.12.0
2.12.0
This release adds support for passing --site-packages-copies to both
pex3 venv create ... and PEX_TOOLS=1 ./my.pex venv .... This is
similar to pex --venv --venv-site-packages-copies ... except that
instead of preferring hard links, a copy is always performed. This is
useful to disassociate venvs you create using Pex from Pex's underlying
PEX_ROOT cache.
This release also adds partial support for statically linked CPython. If
the statically linked CPython is <3.12, the default Pip (
--pip-version vendored) used by Pex will work. All newer Pips will not
though, until Pip 24.2 is released with the fix in
pypa/pip#12716 and Pex releases with support for
--pip-version 24.2.
pex 2.11.0
2.11.0
This release adds support for creating native PEX executables that
contain their own hermetic CPython interpreter courtesy of
Python Standalone Builds and the Science project.
You can now specify --scie {eager,lazy} when building a PEX file and
one or more native executable PEX scies will be produced (one for each
platform the PEX supports). These PEX scies are single file
executables that look and behave like traditional PEXes, but unlike
PEXes they can run on a machine with no Python interpreter available.
- Add
--scieoption to produce native PEX exes. (#2466)
pex 2.10.1
2.10.1
This release fixes a long-standing bug in Pex parsing of editable
requirements. This bug caused PEXes containing local editable project
requirements to fail to import those local editable projects despite
the fact the PEX itself contained them.
- Fix editable requirement parsing. (#2464)
pex 2.10.0
2.10.0
This release adds support for injecting requirements into the isolated
Pip PEXes Pex uses to resolve distributions. The motivating use case
for this is to use the feature Pip 23.1 introduced for forcing
--keyring-provider import.
Pex already supported using a combination of the following to force
non-interactive use of the keyring:
- A
keyringscript installation that was on thePATH - A
--pip-version23.1 or newer. - Specifying
--use-pip-configto pass--keyring-provider subprocess
to Pip.
You could not force --keyring-provider import though, since the Pips
Pex uses are themselves hermetic PEXes without access to extra
installed keyring requirements elsewhere on the system. With
--extra-pip-requirement you can now do this with the primary benefit
over --keyring-provider subprocess being that you do not need to add
the username to index URLs. This is ultimately because the keyring CLI
requires username whereas the API does not; but see
https://pip.pypa.io/en/stable/topics/authentication/#keyring-support for
more information.
- Add support for
--extra-pip-requirement. (#2461)
pex 2.9.0
pex 2.8.1
2.8.1
This release fixes the bdist_pex distutils command to use the
--project option introduced by #2455 in the 2.8.0 release. This
change produces the same results for existing invocations of
python setup.py bdist_pex but allows new uses passing locked project
requirements (either hashed requirement files or Pex lock files) via
--pex-args.
- Fix
bdist_pexto use--project. (#2457)