At a minimum, the Context must implement open(link) by returning a
file-like object. Reference implementations of read(link) and
fetch(link) are provided based upon open(link) but may be further
specialized by individual implementations.

Is this distribution compatible with the given interpreter/platform combination?

Parameters:

interpreter – The Python interpreter against which compatibility should be checked. If None

specified, the current interpreter is used.
:type identity: PythonInterpreter or None
:param platform: The platform against which compatibility should be checked. If None, the current
platform will be used
:type platform: string or None
:returns: True if the distribution is compatible, False if it is unrecognized or incompatible.

PEP425 (http://legacy.python.org/dev/peps/pep-0425/) describes a tagging system used to determine
whether or not a distribution’s platform is compatible with the current platform. It is the
tagging system used to describe platform compatibility for wheel files.

When importing site, modules within sys.modules have their __path__’s populated with
additional paths as defined by *-nspkg.pth in site-packages, or alternately by distribution
metadata such as *.dist-info/namespace_packages.txt. This can possibly cause namespace
packages to leak into imports despite being scrubbed from sys.path.

NOTE: This method mutates modules’ __path__ attributes in sys.module, so this is currently an
irreversible operation.

entry_point (string or None) – The entry point of the PEX in the form of module or module:symbol,
or None.

By default the entry point is None. The behavior of a None entry point is dropping into
an interpreter. If module, it will be executed via runpy.run_module. If
module:symbol, it is equivalent to frommoduleimportsymbol;symbol().

For example, pex_builder.set_shebang(‘/home/wickman/Local/bin/python3.4’). This is
used to override the default behavior which is to have a #!/usr/bin/env line referencing an
interpreter compatible with the one used to build the PEX.

If set to false and the PEX is zipped, the contents of the PEX will be unpacked into a
directory within the PEX_ROOT prior to execution. This allows code and frameworks depending
upon __file__ existing on disk to operate normally.

By default zip_safe is True. May be overridden at runtime by the $PEX_FORCE_LOCAL environment
variable.

requirements – An iterator of Requirement-like things, either
pkg_resources.Requirement objects or requirement strings.

fetchers – (optional) A list of Fetcher objects for locating packages. If
unspecified, the default is to look for packages on PyPI.

interpreter – (optional) A PythonInterpreter object to use for building
distributions and for testing distribution compatibility.

platform – (optional) A PEP425-compatible platform string to use for filtering
compatible distributions. If unspecified, the current platform is used, as determined by
Platform.current().

context – (optional) A Context object to use for network access. If
unspecified, the resolver will attempt to use the best available network context.

precedence – (optional) An ordered list of allowable Package classes
to be used for producing distributions. For example, if precedence is supplied as
(WheelPackage,SourcePackage), wheels will be preferred over building from source, and
eggs will not be used at all. If (WheelPackage,EggPackage) is suppplied, both wheels and
eggs will be used, but the resolver will not resort to building anything from source.

cache – (optional) A directory to use to cache distributions locally.

cache_ttl – (optional integer in seconds) If specified, consider non-exact matches when
resolving requirements. For example, if setuptools==2.2 is specified and setuptools 2.2 is
available in the cache, it will always be used. However, if a non-exact requirement such as
setuptools>=2,<3 is specified and there exists a setuptools distribution newer than
cache_ttl seconds that satisfies the requirement, then it will be used. If the distribution
is older than cache_ttl seconds, it will be ignored. If cache_ttl is not specified,
resolving inexact requirements will always result in making network calls through the
context.

Returns:

List of pkg_resources.Distribution instances meeting requirements.

Raises:

Unsatisfiable – If requirements is not transitively satisfiable.

Untranslateable – If no compatible distributions could be acquired for
a particular requirement.

This method improves upon the setuptools dependency resolution algorithm by maintaining sets of
all compatible distributions encountered for each requirement rather than the single best
distribution encountered for each requirement. This prevents situations where tornado and
tornado==2.0 could be treated as incompatible with each other because the “best
distribution” when encountering tornado was tornado 3.0. Instead, resolve maintains the
set of compatible distributions for each requirement as it is encountered, and iteratively filters
the set. If the set of distributions ever becomes empty, then Unsatisfiable is raised.

Changed in version 0.8: A number of keywords were added to make requirement resolution slightly easier to configure.
The optional obtainer keyword was replaced by fetchers, translator, context,
threads, precedence, cache and cache_ttl, also all optional keywords.

Changed in version 1.0: The translator and threads keywords have been removed. The choice of threading
policy is now implicit. The choice of translation policy is dictated by precedence
directly.

Always write PEX dependencies to disk prior to invoking regardless whether or not the
dependencies are zip-safe. For certain dependencies that are very large such as numpy, this
can reduce the RAM necessary to launch the PEX. The data will be written into $PEX_ROOT,
which by default is $HOME/.pex. Default: false.

Force this PEX to be not-zip-safe. This forces all code and dependencies to be written into
$PEX_ROOT prior to invocation. This is an option for applications with static assets that
refer to paths relative to __file__ instead of using pkgutil/pkg_resources. Default: false.

Allow inheriting packages from site-packages. By default, PEX scrubs any packages and
namespace packages from sys.path prior to invoking the application. This is generally not
advised, but can be used in situations when certain dependencies do not conform to standard
packaging practices and thus cannot be bundled into PEX files. Default: false.

Drop into a REPL instead of invoking the predefined entry point of this PEX. This can be
useful for inspecting the PEX environment interactively. It can also be used to treat the PEX
file as an interpreter in order to execute other scripts in the context of the PEX file, e.g.
“PEX_INTERPRETER=1 ./app.pex my_script.py”. Equivalent to setting PEX_MODULE to empty.
Default: false.

Merge the packages from other PEX files into the current environment. This allows you to
do things such as create a PEX file containing the “coverage” module or create PEX files
containing plugin entry points to be consumed by a main application. Paths should be
specified in the same manner as $PATH, e.g. PEX_PATH=/path/to/pex1.pex:/path/to/pex2.pex
and so forth.

Override the Python interpreter used to invoke this PEX. Can be either an absolute path to an
interpreter or a base name e.g. “python3.3”. If a base name is provided, the $PATH will be
searched for an appropriate match.

The script name within the PEX environment to execute. This must either be an entry point as
defined in a distribution’s console_scripts, or a script as defined in a distribution’s
scripts section. While Python supports any script including shell scripts, PEX only supports
invocation of Python scripts in this fashion.

Set the verbosity level of PEX debug logging. The higher the number, the more logging, with 0
being disabled. This environment variable can be extremely useful in debugging PEX
environment issues. Default: 0