DocsCommunityTestimonialsUsersGitHubTwitterBlogJobs
HomeDocs
DocsCommunityTestimonialsUsersGitHubTwitterBlogJobsTermsPrivacyCookies
TermsPrivacyCookies
Hey! These docs are for version 2.8, which is no longer officially supported. Click here for the latest version, 2.18!

A Python target that can be converted into an executable PEX file.

PEX files are self-contained executable files that contain a complete Python environment capable of running the target. For more information, see [Pex files](🔗).

## <code>dependencies</code>

<span style="color: purple">type: <code>Iterable[str] | None</code></span> <span style="color: green">default: <code>None</code></span>

Addresses to other targets that this target depends on, e.g. ['helloworld/subdir:lib'].

Alternatively, you may include file names. Pants will find which target owns that file, and create a new target from that which only includes the file in its `sources` field. For files relative to the current BUILD file, prefix with `./`; otherwise, put the full path, e.g. ['./sibling.txt', 'resources/demo.json'].

You may exclude dependencies by prefixing with `!`, e.g. `['!helloworld/subdir:lib', '!./sibling.txt']`. Ignores are intended for false positives with dependency inference; otherwise, simply leave off the dependency from the BUILD file.

## <code>description</code>

<span style="color: purple">type: <code>str | None</code></span> <span style="color: green">default: <code>None</code></span>

A human-readable description of the target.

Use `./pants list --documented ::` to see all targets with descriptions.

## <code>emit_warnings</code>

<span style="color: purple">type: <code>bool | None</code></span> <span style="color: green">default: <code>None</code></span>

Whether or not to emit PEX warnings at runtime.

The default is determined by the option `emit_warnings` in the `[pex-binary-defaults]` scope.

## <code>entry_point</code>

<span style="color: purple">type: <code>str | None</code></span> <span style="color: green">default: <code>None</code></span>

Set the entry point, i.e. what gets run when executing `./my_app.pex`, to a module.

You can specify a full module like 'path.to.module' and 'path.to.module:func', or use a shorthand to specify a file name, using the same syntax as the `sources` field:

  1. 'app.py', Pants will convert into the module `path.to.app`;

  2. 'app.py:func', Pants will convert into `path.to.app:func`.

You must use the file name shorthand for file arguments to work with this target.

You may either set this field or the `script` field, but not both. Leave off both fields to have no entry point.

## <code>execution_mode</code>

<span style="color: purple">type: <code>'unzip' | 'venv' | 'zipapp' | None</code></span> <span style="color: green">default: <code>'zipapp'</code></span>

The mode the generated PEX file will run in.

The traditional PEX file runs in a modified 'zipapp' mode (See: https://www.python.org/dev/peps/pep-0441/) where zipped internal code and dependencies are first unpacked to disk. This mode achieves the fastest cold start times and may, for example be the best choice for cloud lambda functions.

The fastest execution mode in the steady state is 'venv', which generates a virtual environment from the PEX file on first run, but then achieves near native virtual environment start times. This mode also benefits from a traditional virtual environment `sys.path`, giving maximum compatibility with stdlib and third party APIs.

The 'unzip' mode is deprecated since the default 'zipapp' mode now executes this way.

## <code>experimental_resolve</code>

<span style="color: purple">type: <code>str | None</code></span> <span style="color: green">default: <code>None</code></span>

The resolve from `[python].experimental_resolves_to_lockfiles` to use, if any.

This field is highly experimental and may change without the normal deprecation policy.

## <code>ignore_errors</code>

<span style="color: purple">type: <code>bool</code></span> <span style="color: green">default: <code>False</code></span>

Should PEX ignore when it cannot resolve dependencies?

## <code>include_tools</code>

<span style="color: purple">type: <code>bool</code></span> <span style="color: green">default: <code>False</code></span>

Whether to include Pex tools in the PEX bootstrap code.

With tools included, the generated PEX file can be executed with `PEX_TOOLS=1 <pex file> --help` to gain access to all the available tools.

## <code>inherit_path</code>

<span style="color: purple">type: <code>'fallback' | 'false' | 'prefer' | None</code></span> <span style="color: green">default: <code>None</code></span>

Whether to inherit the `sys.path` (aka PYTHONPATH) of the environment that the binary runs in.

Use `false` to not inherit `sys.path`; use `fallback` to inherit `sys.path` after packaged dependencies; and use `prefer` to inherit `sys.path` before packaged dependencies.

## <code>interpreter_constraints</code>

<span style="color: purple">type: <code>Iterable[str] | None</code></span> <span style="color: green">default: <code>None</code></span>

The Python interpreters this code is compatible with.

Each element should be written in pip-style format, e.g. `CPython==2.7.*` or `CPython>=3.6,<4`. You can leave off `CPython` as a shorthand, e.g. `>=2.7` will be expanded to `CPython>=2.7`.

Specify more than one element to OR the constraints, e.g. `['PyPy==3.7.*', 'CPython==3.7.*']` means either PyPy 3.7 _or_ CPython 3.7.

If the field is not set, it will default to the option `[python].interpreter_constraints`.

See [Interpreter compatibility](🔗) for how these interpreter constraints are merged with the constraints of dependencies.

## <code>output_path</code>

<span style="color: purple">type: <code>str | None</code></span> <span style="color: green">default: <code>None</code></span>

Where the built asset should be located.

If undefined, this will use the path to the BUILD file, followed by the target name. For example, `src/python/project:app` would be `src.python.project/app.ext.

When running `./pants package`, this path will be prefixed by `--distdir` (e.g. `dist/`).

Warning: setting this value risks naming collisions with other package targets you may have.

## <code>platforms</code>

<span style="color: purple">type: <code>Iterable[str] | None</code></span> <span style="color: green">default: <code>None</code></span>

The platforms the built PEX should be compatible with.

This defaults to the current platform, but can be overridden to different platforms. There must be built wheels available for all of the foreign platforms, rather than sdists.

You can give a list of multiple platforms to create a multiplatform PEX, meaning that the PEX will be executable in all of the supported environments.

Platforms should be in the format defined by Pex (https://pex.readthedocs.io/en/latest/buildingpex.html#platform), i.e. PLATFORM-IMPL-PYVER-ABI (e.g. "linux_x86_64-cp-27-cp27mu", "macosx_10.12_x86_64-cp-36-cp36m"):

  • PLATFORM: the host platform, e.g. "linux-x86_64", "macosx-10.12-x86_64".

  • IMPL: the Python implementation abbreviation, e.g. "cp", "pp", "jp".

  • PYVER: a two-digit string representing the Python version, e.g. "27", "36".

  • ABI: the ABI tag, e.g. "cp36m", "cp27mu", "abi3", "none".

## <code>restartable</code>

<span style="color: purple">type: <code>bool</code></span> <span style="color: green">default: <code>False</code></span>

If true, runs of this target with the `run` goal may be interrupted and restarted when its input files change.

## <code>script</code>

<span style="color: purple">type: <code>str | None</code></span> <span style="color: green">default: <code>None</code></span>

Set the entry point, i.e. what gets run when executing `./my_app.pex`, to a script or console_script as defined by any of the distributions in the PEX.

You may either set this field or the `entry_point` field, but not both. Leave off both fields to have no entry point.

## <code>shebang</code>

<span style="color: purple">type: <code>str | None</code></span> <span style="color: green">default: <code>None</code></span>

Set the generated PEX to use this shebang, rather than the default of PEX choosing a shebang based on the interpreter constraints.

This influences the behavior of running `./result.pex`. You can ignore the shebang by instead running `/path/to/python_interpreter ./result.pex`.

## <code>strip_pex_env</code>

<span style="color: purple">type: <code>bool</code></span> <span style="color: green">default: <code>True</code></span>

Whether or not to strip the PEX runtime environment of `PEX*` environment variables.

Most applications have no need for the `PEX*` environment variables that are used to control PEX startup; so these variables are scrubbed from the environment by Pex before transferring control to the application by default. This prevents any subprocesses that happen to execute other PEX files from inheriting these control knob values since most would be undesired; e.g.: PEX_MODULE or PEX_PATH.

## <code>tags</code>

<span style="color: purple">type: <code>Iterable[str] | None</code></span> <span style="color: green">default: <code>None</code></span>

Arbitrary strings to describe a target.

For example, you may tag some test targets with 'integration_test' so that you could run `./pants --tag='integration_test' test ::` to only run on targets with that tag.