python_requirements

---

Generate a python_requirement for each entry in a requirements.txt-style or PEP 621 compliant pyproject.toml file. The choice of parser for the source field is determined by the file name. If the source field ends with pyproject.toml, then the file is assumed to be a PEP 621 compliant file. Any other file name uses the requirements.txt-style parser.

Further details about pip-style requirements files are available from the PyPA documentation: https://pip.pypa.io/en/latest/reference/requirements-file-format/. However, pip options like --hash are (for now) ignored.

Pants will not follow -r reqs.txt lines. Instead, add a dedicated python_requirements target generator for that additional requirements file.

Further details about PEP 621 and pyproject.toml files are available from the PEP itself: https://peps.python.org/pep-0621/. If the project.optional-dependencies table is included, pants will save the key/name of the optional dependency group as a tag on the generated python_requirement.

Backend: pants.backend.python

---

description

str | None

default: None

A human-readable description of the target.

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

module_mapping

Dict[str, Iterable[str]]

default: FrozenDict({})

A mapping of requirement names to a list of the modules they provide.

For example, {"ansicolors": ["colors"]}.

Any unspecified requirements will use a default. See the modules field from the python_requirement target for more information.

overrides

Dict[Union[str, Tuple[str, ...]], Dict[str, Any]] | None

default: None

Override the field values for generated python_requirement targets.

Expects a dictionary of requirements to a dictionary for the overrides. You may either use a string for a single requirement, or a string tuple for multiple requirements. Each override is a dictionary of field names to the overridden value.

For example:

overrides={
    "django": {"dependencies": ["#setuptools"]]},
    "ansicolors": {"description": "pretty colors"]},
    ("ansicolors, "django"): {"tags": ["overridden"]},
}

Every overridden requirement is validated to be generated by this target.

You can specify the same requirement in multiple keys, so long as you don't override the same field more than one time for the requirement.

resolve

str | None

default: None

The resolve from [python].resolves that this requirement is included in.

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

When generating a lockfile for a particular resolve via the generate-lockfiles goal, it will include all requirements that are declared with that resolve. First-party targets like python_source and pex_binary then declare which resolve they use via their resolve field; so, for your first-party code to use a particular python_requirement target, that requirement must be included in the resolve used by that code.

source

str | None

default: 'requirements.txt'

A single file that belongs to this target.

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

tags

Iterable[str] | None

default: None

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.

type_stubs_module_mapping

Dict[str, Iterable[str]]

default: FrozenDict({})

A mapping of type-stub requirement names to a list of the modules they provide.

For example, {"types-requests": ["requests"]}.

If the requirement is not specified and its name looks like a type stub, Pants will use a default. See the type_stub_modules field from the python_requirement target for more information.