Generate a `python_requirement` for each entry in a Poetry pyproject.toml.
Backend: <span style="color: purple"><code>pants.backend.python</code></span>
## <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>module_mapping</code>
<span style="color: purple">type: <code>Dict[str, Iterable[str]]</code></span> <span style="color: green">default: <code>FrozenDict({})</code></span>
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.
## <code>overrides</code>
<span style="color: purple">type: <code>Dict[Union[str, Tuple[str, ...]], Dict[str, Any]] | None</code></span> <span style="color: green">default: <code>None</code></span>
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:
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.
## <code>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].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.
## <code>source</code>
<span style="color: purple">type: <code>str | None</code></span> <span style="color: green">default: <code>'pyproject.toml'</code></span>
A single file that belongs to this target.
Path is relative to the BUILD file's directory, e.g. `source='example.ext'`.
## <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.
## <code>type_stubs_module_mapping</code>
<span style="color: purple">type: <code>Dict[str, Iterable[str]]</code></span> <span style="color: green">default: <code>FrozenDict({})</code></span>
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.