PEX runtime environment variables¶
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.
Enable coverage reporting for this PEX file. This requires that the “coverage” module is
available in the PEX environment.
Write the coverage data to the specified filename. If PEX_COVERAGE_FILENAME is not
specified but PEX_COVERAGE is, coverage information will be printed to stdout and not saved.
Emit UserWarnings to stderr. When false, warnings will only be logged at PEX_VERBOSE >= 1.
When unset the build-time value of `–emit-warnings` will be used.
A colon-separated string containing paths to add to the runtime sys.path.
Should be used sparingly, e.g., if you know that code inside this PEX needs to
interact with code outside it.
This is distinct from PEX_INHERIT_PATH, which controls how the interpreter’s
existing sys.path (which you may not have control over) is scrubbed.
See also PEX_PATH for how to merge packages from other pexes into the current environment.
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. Also see
PEX_UNZIP which will cause the complete PEX file to be unzipped and re-executed which can
often improve startup latency in addition to providing support for __file__ access.
Ignore any errors resolving dependencies when invoking the PEX file. This can be useful if
you know that a particular failing dependency is not necessary to run the application.
Explicitly disable the reading/parsing of pexrc files (~/.pexrc).
Allow inheriting packages from site-packages, user site-packages and the PYTHONPATH. By
default, PEX scrubs any non stdlib packages from sys.path prior to invoking the application.
Using ‘prefer’ causes PEX to shift any non-stdlib packages before the pex environment on
sys.path and using ‘fallback’ shifts them after instead.
Using this option is generally not advised, but can help in situations when certain
dependencies do not conform to standard packaging practices and thus cannot be bundled into
See also PEX_EXTRA_SYS_PATH for how to *add* to the sys.path.
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.
Override the entry point into the PEX file. Can either be a module, e.g.
‘SimpleHTTPServer’, or a specific entry point in module:symbol form, e.g. “myapp.bin:main”.
A set of one or more PEX files.
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.
See also PEX_EXTRA_SYS_PATH for how to add arbitrary entries to the sys.path.
Enable application profiling. If specified and PEX_PROFILE_FILENAME is not specified, PEX
will print profiling information to stdout.
Profile the application and dump a profile into the specified filename in the standard
“profile” module format.
Toggle the profile sorting algorithm used to print out profile columns.
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.
A colon-separated string containing paths of blessed Python interpreters
for overriding the Python interpreter used to invoke this PEX. Can be absolute paths to
interpreters or standard $PATH style directory entries that are searched for child files that
are python binaries.
The directory location for PEX to cache any dependencies and code. PEX must write not-zip-
safe eggs and all wheels to disk in order to activate them.
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.
Enable verbosity for when the interpreter shuts down. This is mostly only useful for
debugging PEX itself.
Run the PEX tools.
Force this PEX to unzip itself to $PEX_ROOT and re-execute from there. If the pex file will
be run multiple times under a stable $PEX_ROOT the unzipping will only be performed once and
subsequent runs will enjoy lower startup latency.
Force this PEX to create a venv under $PEX_ROOT and re-execute from there. If the pex file
will be run multiple times under a stable $PEX_ROOT the venv creation will only be performed
once and subsequent runs will enjoy lower startup latency.
When running in PEX_VENV mode, optionally add the scripts and console scripts of
distributions in the PEX file to the $PATH.
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