# Release Notes ## 2.20.1 This release fixes Pex `--interpreter-constraint` handling such that any supplied interpreter constraints which are in principle unsatisfiable either raise an error or else cause a warning to be issued when other viable interpreter constraints have also been specified. For example, `--interpreter-constraint ==3.11.*,==3.12.*` now errors and `--interpreter-constraint '>=3.8,<3.8' --interpreter-constraint ==3.9.*` now warns, culling `>3.8,<3.8` and continuing using only `==3.9.*`. * Pre-emptively cull unsatisfiable interpreter constraints. (#2542) ## 2.20.0 This release adds the `--pip-log` alias for the existing `--preserve-pip-download-log` option as well as the ability to specify the log file path. So, to debug a resolve, you can now specify `--pip-log log.txt` and Pex will deposit the Pip resolve log to `log.txt` in the current directory for easy tailing or post-resolve inspection. In addition, the log file itself is more useful in some cases. When you specify any abbreviated `--platform` targets, those targets calculated wheel compatibility tags are included in the Pip log. Also, when multiple targets are specified, their log outputs are now merged at the end of the resolve in a serialized fashion with prefixes on each log line indicating which target the log line corresponds to. In addition, a race in Pex's PEP-517 implementation that could (rarely) lead to spurious metadata generation errors or sdist creation errors is fixed. * Fix intermittent PEP-517 failures. (#2540) * Plumb `--pip-version` to Platform tag calculation. (#2538) * Add the ability to specify the `--pip-log` path. (#2536) ## 2.19.1 This release fixes a regression introduced by #2512 in the 2.19.0 release when building PEXes using abbreviated `--platform` targets. Instead of failing certain builds that used to succeed, Pex now warns that the resulting PEX may fail at runtime and that `--complete-platform` should be used instead. * Only warn when `--platform` resolves fail tag checks. (#2533) ## 2.19.0 This release adds support for a new `--pre-resolved-dists` resolver as an alternative to the existing Pip resolver, `--lock` resolver and `--pex-repository` resolvers. Using `--pre-resolved-dists dists/dir/` behaves much like `--no-pypi --find-links dists/dir/` except that it is roughly 3x faster. * Support `--pre-resolved-dists` resolver. (#2512) ## 2.18.1 This release fixes `--scie-name-style platform-parent-dir` introduced in #2523. Previously the target platform name also leaked into scies targeting foreign platforms despite using this option. * Fix `--scie-name-style platform-parent-dir`. (#2526) ## 2.18.0 This release adds support for `pex3 cache {dir,info,purge}` for inspecting and managing the Pex cache. Notably, the `pex3 cache purge` command is safe in the face of concurrent PEX runs, waiting for in flight PEX runs to complete and blocking new runs from starting once the purge is in progress. N.B.: when using `pex3 cache purge` it is best to install Pex with the 'management' extra; e.g.: `pip install pex[management]`. Alternatively, one of the new Pex scie binary releases can be used. In order to release a Pex binary that can support the new `pex3` cache management commands first class, a set of enhancements to project locking and scie generation were added. When using `--project` you can now specify extras; e.g.: `--project ./the/project-dir[extra1,extra2]`. When creating a Pex scie, you can now better control the output files using `--scie-only` to ensure no PEX file is emitted and `--scie-name-style` to control how the scie target platform name is mixed into the scie output file name. Additionally, you can request one or more shasum-compatible checksum files be emitted for each scie with `--scie-hash-alg`. On the locking front, an obscure bug locking project releases that contain artifacts that mis-report their version number via their file name has been fixed. Finally, the vendored Pip has had its own vendored CA cert bundle upgraded from that in certifi 2024.7.4 to that in certifi 2024.8.30. * Fix locking of sdists rejected by Pip. (#2524) * Add `--scie-only` & `--scie-name-style`. (#2523) * Support `--project` extras. (#2522) * Support shasum file gen via `--scie-hash-alg`. (#2520) * Update vendored Pip's CA cert bundle. (#2517) * Introduce `pex3 cache {dir,info,purge}`. (#2513) ## 2.17.0 This release brings support for overriding the versions of setuptools and wheel Pex bootstraps for non-vendored Pip versions (the modern ones you select with `--pip-version`) using the existing `--extra-pip-requirement` option introduced in the [2.10.0 release]( https://github.com/pex-tool/pex/releases/tag/v2.10.0). * Support custom setuptools & wheel versions. (#2514) ## 2.16.2 This release brings a slew of small fixes across the code base. When creating locks for foreign platforms, `pex3 lock {create,update,sync}` now allows locking sdists that use PEP-517 build backends that do not support the `prepare_metadata_for_build_wheel` hook and whose product is a wheel not compatible with the foreign platform. This is decidedly a corner case, but one encountered with the `mesonpy` build backend which seems to have traction in the scientific computing world in particular. The recent re-vamp of the PEX REPL is now fixed to respect common conventions for controlling terminal output via the `NO_COLOR`, `FORCE_COLOR` and `TERM` environment variables. The examples in the [buildingpex docs]( https://docs.pex-tool.org/buildingpex.html) had bit-rotted. They have been refreshed and now all work. Finally, both the Pex CLI and PEX files support the ambient OS standards for user cache directories. Instead of using `~/.pex` as the default `PEX_ROOT` cache location, the default is now `~/.cache/pex` on Linux ( but respecting `XDG_CACHE_HOME` when set) and `~/Library/Caches/pex` on Mac. * Lock sdists in more cases for foreign platforms. (#2508) * Respect `NO_COLOR`, `FORCE_COLOR` & `TERM=dumb`. (#2507) * Fix `buildingpex.rst` examples. (#2506) * Respect OS user cache location conventions. (#2505) ## 2.16.1 This release fixes the PEX repl for [Python Standalone Builds][PBS] Linux CPython PEX scies. These PEXes ship using a version of libedit for readline support that does not support naive use of ansi terminal escape sequences for prompt colorization. * Fix PEX repl prompt for Linux PBS libedit. (#2503) ## 2.16.0 This release adds support for `--venv-system-site-packages` when creating a `--venv` PEX and `--system-site-packages` when creating a venv using the `pex-tools` / `PEX_TOOLS=1` `venv` command or when using the `pex3 venv create` command. Although this breaks PEX hermeticity, it can be the most efficient way to ship partial PEX venvs created with `--exclude`s to machines that have the excluded dependencies already installed in the site packages of a compatible system interpreter. * Support `--system-site-packages` when creating venvs. (#2500) ## 2.15.0 This release enhances the REPL your PEX drops into when it either doesn't have an entry point or you force interpreter mode with the `PEX_INTERPRETER` environment variable. There is now clear indication you are running in a PEX hermetic environment and a `pex` command added to the REPL that you can use to find out more details about the current PEX environment. * Add PEX info to the PEX repl. (#2496) ## 2.14.1 This release fixes `--inject-env` when used in combination with a `--scie-busybox` so that the injected environment variable can be overridden at runtime like it can form a traditional PEX. In addition, running a PEX with the Python interpreter `-i` flag or `PYTHONINSPECT=x` in the environment causes the PEX to enter the Python REPL after evaluating the entry point, if any. * Allow `--inject-env` overrides for `--scie-busybox`. (#2490) * Fix PEXes for `-i` / `PYTHONINSPECT=x`. (#2491) ## 2.14.0 This release brings support for creating PEX scies for PEXes targeting [PyPy][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][PBS] 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][BusyBox]-like scie. This support is documented in depth at https://docs.pex-tool.org/scie.html * Support `--scie` for PyPy & support stripped CPython. (#2488) * Add support for `--scie-busybox`. (#2468) [PyPy]: https://pypy.org/ [BusyBox]: https://www.busybox.net/ ## 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) ## 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`. * Add more context for Job errors. (#2479) * Add support for `--pip-version 24.2`. (#2481) ## 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]( 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) ## 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 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) ## 2.11.0 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/indygreg/python-build-standalone [scie]: https://github.com/a-scie * Add `--scie` option to produce native PEX exes. (#2466) ## 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) ## 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: 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) ## 2.9.0 This release adds support for Pip 24.1.2. * Add support for `--pip-version 24.1.2`. (#2459) ## 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_pex` to use `--project`. (#2457) ## 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 `--override`s and the existing `--exclude`s 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. * Add support for `--override`. (#2431) * Support `--project` locking and PEX building. (#2455) * Improve venv creation robustness when adding Pip. (#2454) ## 2.7.0 This release adds support for Pip 24.1.1. * Add support for `--pip-version 24.1.1`. (#2451) ## 2.6.3 There are no changes to Pex code or released artifacts over 2.6.1 or 2.6.2, just a further fix to the GitHub Releases release process which #2442 broke and #2444 only partially fixed. * Fix GitHub Releases deployment. (#2448) ## 2.6.2 > [!NOTE] > Although 2.6.2 successfully released to [PyPI]( > https://pypi.org/project/pex/2.6.2/), it failed to release to GitHub > Releases (neither the Pex PEX nor the pex.pdf were published.) You > can use Pex 2.6.3 instead which has no Pex code changes over this > release. There are no changes to Pex code or released artifacts over 2.6.1, just a fix to the GitHub Releases release process which #2442 broke. * Fix GitHub Releases deployment. (#2444) ## 2.6.1 > [!NOTE] > Although 2.6.1 successfully released to [PyPI]( > https://pypi.org/project/pex/2.6.1/), it failed to release to GitHub > Releases (neither the Pex PEX nor the pex.pdf were published.) You > can use Pex 2.6.3 instead which has no Pex code changes over this > release. This release improves error messages when attempting to read invalid metadata from distributions such that the problematic distribution is always identified. * Improve errors for invalid distribution metadata. (#2443) ## 2.6.0 This release adds support for [PEP-723]( https://peps.python.org/pep-0723) script metadata in `--exe`s. For such a script with metadata describing its dependencies or Python version requirements, running the script is as simple as `pex --exe