Releases: pex-tool/pex
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)
pex 2.8.0
2.8.0
This release adds a new --override option to resolves that ultimately
use an --index or --find-links. This allows you to override
transitive dependencies when you have determined they are too narrow and
that expanding their range is safe to do. The new --overrides and the
existing --excludes can now also be specified when creating or syncing
a lock file to seal these dependency modifications into the lock.
This release also adds a new --project option to pex and
pex3 lock {create,sync} that improves the ergonomics of locking a
local Python project and then creating PEX executables for that project
using its locked requirements.
In addition, this release fixes the bdist_pex distutils command that
ships with Pex to work when run under tox and Python 3.12 by improving
Pex venv creation robustness when creating venvs that include Pip.