Pex

Latest version: v2.33.7

Safety actively analyzes 723177 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 19 of 57

2.1.128

This release fixes a regression introduced in Pex 2.1.120 that caused
`--no-venv-site-packages-copies` (the default when using `--venv`) to
be ignored for both zipapp PEXes (the default) and `--layout packed`
PEXes.

* Fix regression in venv symlinking. (2090)

2.1.127

This release fixes `--lock` resolve sub-setting for local project
requirements.

* Fix lock subsetting for local projects. (2085)

2.1.126

This release fixes a long-standing (> 4 years old!) concurrency bug
when building the same sdist for the 1st time and racing another Pex
process doing the same sdist build.

* Guard against racing sdist builds. (2080)

2.1.125

This release makes `--platform` and `--complete-platform` resolves and
locks as permissive as possible. If such a resolve or lock only has an
sdist available for a certain project, that sdist will now be used if it
builds to a wheel compatible with the specified foreign platform(s).

* Attempt "cross-builds" of sdists for foreign platforms. (2075)

2.1.124

This release adds support for specifying `--non-hermetic-venv-scripts`
when building a `--venv` PEX. This can be useful when integrating with
frameworks that do setup via `PYTHONPATH` manipulation.

Support for Pip 23.0.1 and setuptools 67.4.0 is added via
`--pip-version 23.0.1`.

Additionally, more work towards hardening Pex against rare concurrency
issues in its atomic directory handling is included.

* Introduce `--non-hermetic-venv-scripts`. (2068)
* Wrap inter-process locks in in-process locks. (2070)
* Add support for Pip 23.0.1. (2072)

2.1.123

This release fixes a few `pex3 lock create` bugs.

There was a regression introduced in Pex 2.1.122 where projects that
used a PEP-518 `[build-system] requires` but specified no corresponding
`build-backend` would fail to lock.

There were also two long-standing issues handling more exotic direct
reference URL requirements. Source archives with names not following the
standard Python sdist naming scheme of
`<project name>-<version>.{zip,tar.gz}` would cause a lock error. An
important class of these is provided by GitHub's magic source archive
download URLs. Also, although local projects addressed with Pip
proprietary support for pure local path requirements would lock, the
same local projects addressed via
`<project name> file://<local project path>` would also cause a lock
error. Both of these cases are now fixed and can be locked successfully.

When locking with an `--interpreter-constraint`, any resolve traversing
wheels using the `pypyXY` or `cpythonXY` python tags would cause the
lock to error. Wheels with this form of python tag are now handled
correctly.

* Handle `[build-system]` with no build-backend. (2064)
* Handle locking all direct reference URL forms. (2060)
* Fix python tag handling in IC locks. (2061)

Page 19 of 57

Links

Releases

Has known vulnerabilities

© 2025 Safety CLI Cybersecurity Inc. All Rights Reserved.