The pytest Python test framework (https://docs.pytest.org/).
--pytest-args="[<shell_str>, <shell_str>, ...]", ... -- [<shell_str> [<shell_str> [...]]]
Arguments to pass directly to Pytest, e.g.
--pytest-args='-k test_foo --quiet'.
If true, Pants will use
pytest-xdist (https://pytest-xdist.readthedocs.io/en/latest/) to parallelize tests within each
pytest-xdist can cause high-level scoped fixtures (for example
session) to execute more than once. See the
pytest-xdist docs for more info: https://pypi.org/project/pytest-xdist/#making-session-scoped-fixtures-execute-only-once
If true, don't use Pytest when running
Requirement string for the tool.
--pytest-extra-requirements="['<str>', '<str>', ...]"
[ "pytest-cov>=2.12,!=2.12.1,<3.1", "pytest-xdist>=2.5,<3" ]
Any additional requirement strings to use with the tool. This is useful if the tool allows you to install plugins or if you need to constrain a dependency to a certain version.
Path to a lockfile used for installing the tool.
Set to the string
<default> to use a lockfile provided by Pants, so long as you have not changed the
--extra-requirements options, and the tool's interpreter constraints are compatible with the default. Pants will error or warn if the lockfile is not compatible (controlled by
[python].invalid_lockfile_behavior). See https://github.com/pantsbuild/pants/blob/release_2.15.1rc1/src/python/pants/backend/python/subsystems/pytest.lock for the default lockfile contents.
Set to the string
<none> to opt out of using a lockfile. We do not recommend this, though, as lockfiles are essential for reproducible builds and supply-chain security.
To use a custom lockfile, set this option to a file path relative to the build root, then run
pants generate-lockfiles --resolve=pytest.
Alternatively, you can set this option to the path to a custom lockfile using pip's requirements.txt-style, ideally with
[python].invalid_lockfile_behavior = 'ignore' so that Pants does not complain about missing lockfile headers.
The console script for the tool. Using this option is generally preferable to (and mutually exclusive with) specifying an --entry-point since console script names have a higher expectation of staying stable across releases of the tool. Usually, you will not want to change this from the default.
The entry point for the tool. Generally you only want to use this option if the tool does not offer a --console-script (which this option is mutually exclusive with). Usually, you will not want to change this from the default.
The format of generated junit XML files. See https://docs.pytest.org/en/latest/reference.html#confval-junit_family.
If a non-empty string, the process execution slot id (an integer) will be exposed to tests under this environment variable name.
Path to a config file understood by Pytest (https://docs.pytest.org/en/latest/reference/customize.html#configuration-file-formats). Setting this option will disable
[pytest].config_discovery. Use this option if the config is located in a non-standard location.
If true, Pants will include all relevant Pytest config files (e.g.
pytest.ini) during runs. See https://docs.pytest.org/en/stable/customize.html#finding-the-rootdir for where config files should be located for Pytest to discover them.
[pytest].config instead if your config is in a non-standard location.
Deprecated, is scheduled to be removed in version: 2.23.0.dev0.
Use the export goal's --resolve option to select tools to export, instead of using this option to exempt a tool from export-by-default.
If true, export a virtual environment with Pytest when running
This can be useful, for example, with IDE integrations to point your editor to the tool's binary.
Updated about 4 hours ago