# Release Notes ## 2.24.1 This release fixes `pex3 cache prune` handling of cached Pips. Previously, performing a `pex3 cache prune` would bump the last access time of all un-pruned cached Pips artificially. If you ran `pex3 cache prune` in a daily or weekly cron job, this would mean Pips would never be pruned. * Fix `pex3 cache prune` handling of cached Pips. (#2589) ## 2.24.0 This release adds `pex3 cache prune` as a likely more useful Pex cache management command than the existing `pex3 cache purge`. By default `pex3 cache prune` prunes any cached items not used for the last 2 weeks and is likely suitable for use as a daily cron job to keep Pex cache sizes down. The default age of 2 weeks can be overridden by specifying `--older-than "1 week"` or `--last-access-before 14/3/2024`, etc. See `pex3 cache prune --help` for more details. * Support `pex3 cache prune --older-than ...`. (#2586) ## 2.23.0 This release adds support for drawing requirements from [PEP-735][PEP-735] dependency groups when creating PEXes or lock files. Groups are requested via `--group @` or just `--group ` if the project directory is the current working directory. * Add support for PEP-735 dependency groups. (#2584) [PEP-735]: https://peps.python.org/pep-0735/ ## 2.22.0 This release adds support for `--pip-version 24.3.1`. * Add support for `--pip-version 24.3.1`. (#2582) ## 2.21.0 This release adds support for `--pip-version 24.3`. * Add support for `--pip-version 24.3`. (#2580) ## 2.20.4 This release carries several bug fixes and a performance improvement for lock deletes. Although there were no direct reports in the wild, @iritkatriel noticed by inspection the Pex `safe_mkdir` utility function would mask any `OSError` besides `EEXIST`. This is now fixed. It was observed by @b-x that when `PEX_ROOT` was contained in a symlinked path, PEXes would fail to execute. The most likely case leading to this would be a symlinked `HOME` dir. This is now fixed. This release also fixes a bug where `--pip-log `, used multiple times in a row against the same file could lead to `pex3 lock` errors. Now the specified path is always truncated before use and a note has been added to the option `--help` that using the same `--pip-log` path in concurrent Pex runs is not supported. In addition, `pex3 lock {update,sync}` is now optimized for the cases where all the required updates are deletes. In this case neither Pip nor the network are consulted leading to speed improvements proportional to the size of the resolve. * Fix `safe_mkdir` swallowing non-`EEXIST` errors. (#2575) * Fix `PEX_ROOT` handling for symlinked paths. (#2574) * Fix `--pip-log` re-use. (#2570) * Optimize pure delete lock updates. (#2568) ## 2.20.3 This release fixes both PEX building and lock creation via `pex3 lock {create,sync}` to be reproducible in more cases. Previously, if a requirement only available in source form (an sdist, a local project or a VCS requirement) had a build that was not reproducible due to either file timestamps (where the `SOURCE_DATE_EPOCH` standard was respected) or random iteration order (e.g.: the `setup.py` used sets in certain in-opportune ways), Pex's outputs would mirror the problematic requirement's non-reproducibility. Now Pex plumbs a fixed `SOURCE_DATE_EPOCH` and `PYTHONHASHSEED` to all places sources are built. * Plumb reproducible build env vars more thoroughly. (#2554) ## 2.20.2 This release fixes an old bug handling certain sdist zips under Python 2.7 as well missing support for Python 3.13's `PYTHON_COLORS` env var. * Fix Zip extraction UTF-8 handling for Python 2.7. (#2546) * Add repl support for `PYTHON_COLORS`. (#2545) ## 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