Version: 2.23

python_test

A single Python test file, written in either Pytest style or unittest style.

All test util code, including conftest.py, should go into a dedicated python_source target and then be included in the dependencies field. (You can use the python_test_utils target to generate these python_source targets.)

See https://www.pantsbuild.org/2.23/docs/python/goals/test

Backend: pants.backend.python

`source`

str

required

A single file that belongs to this target.

Path is relative to the BUILD file's directory, e.g. source='example.ext'.

`batch_compatibility_tag`

str | None

default: None

An arbitrary value used to mark the test files belonging to this target as valid for batched execution.

It's sometimes safe to run multiple python_tests within a single test runner process, and doing so can give significant wins by allowing reuse of expensive test setup / teardown logic. To opt into this behavior, set this field to an arbitrary non-empty string on all the python_test targets that are safe/compatible to run in the same process.

If this field is left unset on a target, the target is assumed to be incompatible with all others and will run in a dedicated pytest process.

If this field is set on a target, and its value is different from the value on some other test python_test, then the two targets are explicitly incompatible and are guaranteed to not run in the same pytest process.

If this field is set on a target, and its value is the same as the value on some other python_test, then the two targets are explicitly compatible and may run in the same test runner process. Compatible tests may not end up in the same test runner batch if:

There are "too many" compatible tests in a partition, as determined by the [test].batch_size config parameter, or
Compatible tests have some incompatibility in Pants metadata (i.e. different resolves or extra_env_vars).

When tests with the same batch_compatibility_tag have incompatibilities in some other Pants metadata, they will be automatically split into separate batches. This way you can set a high-level batch_compatibility_tag using __defaults__ and then have tests continue to work as you tweak BUILD metadata on specific targets.

`dependencies`

Iterable[str] | None

default: None

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.23/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.

`description`

str | None

default: None

A human-readable description of the target.

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

`entry_point_dependencies`

Dict[str, Iterable[str]] | None

default: None

backend: pants.backend.experimental.python

Dependencies on entry point metadata of python_distribution targets.

This is a dict where each key is a python_distribution address and the value is a list or tuple of entry point groups and/or entry points on that target. The strings in the value list/tuple must be one of: - "entry.point.group/entry-point-name" to depend on a named entry point - "entry.point.group" (without a "/") to depend on an entry point group - "*" to get all entry points on the target

For example:

entry_point_dependencies={
    "//foo/address:dist_tgt": ["*"], # all entry points
    "bar:dist_tgt": ["console_scripts"], # only from this group
    "foo/bar/baz:dist_tgt": ["console_scripts/my-script"], # a single entry point
    "another:dist_tgt": [ # multiple entry points
        "console_scripts/my-script",
        "console_scripts/another-script",
        "entry.point.group/entry-point-name",
        "other.group",
        "gui_scripts",
    ],
}

Code for matching entry_points on python_distribution targets will be added as dependencies so that they are available on PYTHONPATH during tests.

Plus, an entry_points.txt file will be generated in the sandbox so that each of the python_distributions appear to be "installed". The entry_points.txt file will only include the entry points requested on this field. This allows the tests, or the code under test, to lookup entry points metadata using something like pkg_resources.iter_entry_points from setuptools.

`environment`

str | None

default: '__local__'

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.

`extra_env_vars`

Iterable[str] | None

default: None

Additional environment variables to include in test processes.

Entries are strings in the form ENV_VAR=value to use explicitly; or just ENV_VAR to copy the value of a variable in Pants's own environment.

This will be merged with and override values from [test].extra_env_vars.

`interpreter_constraints`

Iterable[str] | None

default: None

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.23/docs/python/overview/interpreter-compatibility for how these interpreter constraints are merged with the constraints of dependencies.

`resolve`

str | None

default: None

The resolve from [python].resolves to use.

If not defined, will default to [python].default_resolve.

All dependencies must share the same value for their resolve field.

`run_goal_use_sandbox`

bool | None

default: None

Whether to use a sandbox when running this target. Defaults to [python].default_run_goal_use_sandbox.

If true, runs of this target with the run goal will copy the needed first-party sources into a temporary sandbox and run from there.

If false, runs of this target with the run goal will use the in-repo sources directly.

Note that this field only applies when running a target with the run goal. No other goals (such as test, if applicable) consult this field.

The former mode is more hermetic, and is closer to building and running the source as it were packaged in a pex_binary. Additionally, it may be necessary if your sources depend transitively on "generated" files which will be materialized in the sandbox in a source root, but are not in-repo.

The latter mode is similar to creating, activating, and using a virtual environment when running your files. It may also be necessary if the source being run writes files into the repo and computes their location relative to the executed files. Django's makemigrations command is an example of such a process.

`runtime_package_dependencies`

Iterable[str] | None

`timeout`

int | None

default: None

A timeout (in seconds) used by each test file belonging to this target.

If unset, will default to [test].timeout_default; if that option is also unset, then the test will never time out. Will never exceed [test].timeout_maximum. Only applies if the option --test-timeouts is set to true (the default).

`xdist_concurrency`

int | None

default: None

Maximum number of CPUs to allocate to run each test file belonging to this target.

Tests are spread across multiple CPUs using pytest-xdist (https://pytest-xdist.readthedocs.io/en/latest/index.html). Use of pytest-xdist must be enabled using the [pytest].xdist_enabled option for this field to have an effect.

If pytest-xdist is enabled and this field is unset, Pants will attempt to derive the concurrency for test sources by counting the number of tests in each file.

Set this field to 0 to explicitly disable use of pytest-xdist for a target.

source​

batch_compatibility_tag​

dependencies​

description​

entry_point_dependencies​

environment​

extra_env_vars​

interpreter_constraints​

resolve​

run_goal_use_sandbox​

runtime_package_dependencies​

skip_add_trailing_comma​

skip_autoflake​

skip_bandit​

skip_black​

skip_docformatter​

skip_flake8​

skip_isort​

skip_mypy​

skip_pydocstyle​

skip_pylint​

skip_pyright​

skip_pytype​

skip_pyupgrade​

skip_ruff​

skip_ruff_check​

skip_ruff_format​

skip_tests​

skip_yapf​

stevedore_namespaces​

tags​

timeout​

xdist_concurrency​

`source`

`batch_compatibility_tag`

`dependencies`

`description`

`entry_point_dependencies`

`environment`

`extra_env_vars`

`interpreter_constraints`

`resolve`

`run_goal_use_sandbox`

`runtime_package_dependencies`

`skip_add_trailing_comma`

`skip_autoflake`

`skip_bandit`

`skip_black`

`skip_docformatter`

`skip_flake8`

`skip_isort`

`skip_mypy`

`skip_pydocstyle`

`skip_pylint`

`skip_pyright`

`skip_pytype`

`skip_pyupgrade`

`skip_ruff`

`skip_ruff_check`

`skip_ruff_format`

`skip_tests`

`skip_yapf`

`stevedore_namespaces`

`tags`

`timeout`

`xdist_concurrency`