Pex

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`.

* Add more context for Job errors. (2479)
* Add support for `--pip-version 24.2`. (2481)

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](
https://pypi.org/project/certifi/2019.9.11/)'s `cacert.pem` to
[certifi 2024.7.4](https://pypi.org/project/certifi/2024.7.4/)'s
`cacert.pem`. This refresh addresses at least [CVE-2023-37920](
https://nvd.nist.gov/vuln/detail/CVE-2023-37920) and was spearheaded by
a contribution from [Nash Kaminski](https://github.com/gs-kamnas) in
https://github.com/pex-tool/pip/pull/12. Thank you, Nash!

* Update vendored Pip's CA cert bundle. (2476)

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
https://github.com/pypa/pip/pull/12716 and Pex releases with support for
`--pip-version 24.2`.

* Add `--site-packages-copies` for external venvs. (2470)
* Support statically linked CPython. (2472)

This release adds support for creating native PEX executables that
contain their own hermetic CPython interpreter courtesy of
[Python Standalone Builds][PBS] and the [Science project][scie].

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.

[PBS]: https://github.com/astral-sh/python-build-standalone
[scie]: https://github.com/a-scie

* Add `--scie` option to produce native PEX exes. (2466)

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)

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:
1. A `keyring` script installation that was on the `PATH`
2. A `--pip-version` 23.1 or newer.
3. Specifying `--use-pip-config` to 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)