pex_binary

Freeze these command-line args into the PEX. Allows you to run generic entry points on specific arguments without creating a shim file.

This is different to extra_build_args : args records arguments used by the packaged PEX when executed, extra_build_args passes arguments to the process that does the packaging.

Check that the built PEX is valid. Currently this only applies to --layout zipapp where the PEX zip is tested for importability of its __main__ module by the Python zipimport module. This check will fail for PEX zips that use ZIP64 extensions since the Python zipimport zipimporter only works with 32 bit zips. The check no-ops for all other layouts.

The platforms the built PEX should be compatible with.

There must be built wheels available for all of the foreign platforms, rather than sdists.

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

Complete platforms should be addresses of file or resource targets that point to files that contain complete platform JSON as described by Pex ( https://pex.readthedocs.io/en/latest/buildingpex.html#complete-platform ).

See https://www.pantsbuild.org/2.30/docs/python/overview/pex#generating-the-complete_platforms-file for details on how to create this file.

Addresses to other targets that this target depends on, e.g. ['helloworld/subdir:lib', 'helloworld/main.py:lib', '3rdparty:reqs#django'] .

This augments any dependencies inferred by Pants, such as by analyzing your imports. Use pants dependencies or pants peek on this target to get the final result.

See https://www.pantsbuild.org/2.30/docs/using-pants/key-concepts/targets-and-build-files for more about how addresses are formed, including for generated targets. You can also run pants list :: to find all addresses in your project, or pants list dir to find all addresses defined in that directory.

If the target is in the same BUILD file, you can leave off the BUILD file path, e.g. :tgt instead of helloworld/subdir:tgt . For generated first-party addresses, use ./ for the file path, e.g. ./main.py:tgt ; for all other generated targets, use :tgt#generated_name .

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.

A human-readable description of the target.

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

Whether or not to emit PEX warnings at runtime.

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

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 may only set one of: this field, or the script field, or the executable field. Leave off all three fields to have no entry point.

Freeze these environment variables into the PEX. Allows you to run generic entry points on a specific environment without creating a shim file.

Specify which environment target to consume environment-sensitive options from.

Once environments are defined in [environments-preview].names , you can specify the environment for this target by its name. Any fields that are defined in that environment will override the values from options set by pants.toml , command line values, or environment variables.

You can specify multiple valid environments by using parametrize . If __local__ is specified, Pants will fall back to the local_environment defined for the current platform, or no environment if no such environment exists.

Set the entry point, i.e. what gets run when executing ./my_app.pex , to an execuatble local python script. This executable python script is typically something that cannot be imported so it cannot be used via script or entry_point .

You may only set one of: this field, or the entry_point field, or the script field. Leave off all three fields to have no entry point.

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.

Extra arguments to pass to the pex invocation used to build this PEX. These are passed after all other arguments. This can be used to pass extra options that Pants doesn't have built-in support for.

This is different to args : args records arguments used by the packaged PEX when executed, extra_build_args passes arguments to the process that does the packaging.

Should PEX ignore errors when it cannot resolve dependencies?

Whether to include the third party requirements the binary depends on in the packaged PEX file.

Whether to include your first party sources the binary uses in the packaged PEX file.

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.

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.

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 https://www.pantsbuild.org/2.30/docs/python/overview/interpreter-compatibility for how these interpreter constraints are merged with the constraints of dependencies.

The layout used for the PEX binary.

By default, a PEX is created as a single file zipapp, but either a packed or loose directory tree based layout can be chosen instead.

A packed layout PEX is an executable directory structure designed to have cache-friendly characteristics for syncing incremental updates to PEXed applications over a network. At the top level of the packed directory tree there is an executable __main__.py script. The directory can also be executed by passing its path to a Python executable; e.g: python packed-pex-dir/ . The Pex bootstrap code and all dependency code are packed into individual zip files for efficient caching and syncing.

A loose layout PEX is similar to a packed PEX, except that neither the Pex bootstrap code nor the dependency code are packed into zip files, but are instead present as collections of loose files in the directory tree providing different caching and syncing tradeoffs.

Both zipapp and packed layouts install themselves in the $PEX_ROOT as loose apps by default before executing, but these layouts compose with execution_mode='zipapp' as well.

Where the built asset should be located.

This field supports the following template replacements:

${spec_path_normalized} : The path to the target's directory ("spec path") with forward slashes replaced by dots.

${target_name_normalized} : The target's name with paramaterizations escaped by replacing dots with underscores.