python_sources

Generate a `python_source` target for each file in the `sources` field.
You can either use this target generator or `python_test_utils` for test utility files like `conftest.py`. They behave identically, but can help to better model and keep separate test support files vs. production files.
Backend: <span style="color: purple"><code>pants.backend.python</code></span>
## <code>dependencies</code>
<span style="color: purple">type: <code>Iterable[str] | None</code></span>
<span style="color: green">default: <code>None</code></span>
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 [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.
## <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>interpreter_constraints</code>
<span style="color: purple">type: <code>Iterable[str] | None</code></span>
<span style="color: green">default: <code>None</code></span>
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 [Interpreter compatibility](🔗﻿) for how these interpreter constraints are merged with the constraints of dependencies.
## <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 `{generated_target_name}` targets.
Expects a dictionary of relative file paths and globs to a dictionary for the overrides. You may either use a string for a single path / glob, or a string tuple for multiple paths / globs. Each override is a dictionary of field names to the overridden value.
For example:
    overrides={
        "foo.py": {"skip_pylint": True]},
        "bar.py": {"skip_flake8": True]},
        ("foo.py", "bar.py"): {"tags": ["linter_disabled"]},
    }"
File paths and globs are relative to the BUILD file's directory. Every overridden file is validated to belong to this target's `sources` field.
If you'd like to override a field's value for every `python_source` target generated by this target, change the field directly on this target rather than using the `overrides` field.
You can specify the same file name in multiple keys, so long as you don't override the same field more than one time for the file.
## <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` to use.
If not defined, will default to `[python].default_resolve`.
All dependencies must share the same value for their `resolve` field.
## <code>run_goal_use_sandbox</code>
<span style="color: purple">type: <code>bool | None</code></span>
<span style="color: green">default: <code>None</code></span>
Whether to use a sandbox when `run`ning this target. Defaults to `[python].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.
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.
## <code>skip_autoflake</code>
<span style="color: purple">type: <code>bool</code></span>
<span style="color: green">default: <code>False</code></span>
backend: <span style="color: green"><code>pants.backend.experimental.python.lint.autoflake</code></span>
If true, don't run Autoflake on this target's code.
## <code>skip_bandit</code>
<span style="color: purple">type: <code>bool</code></span>
<span style="color: green">default: <code>False</code></span>
backend: <span style="color: green"><code>pants.backend.python.lint.bandit</code></span>
If true, don't run Bandit on this target's code.
## <code>skip_black</code>
<span style="color: purple">type: <code>bool</code></span>
<span style="color: green">default: <code>False</code></span>
backend: <span style="color: green"><code>pants.backend.python.lint.black</code></span>
If true, don't run Black on this target's code.
## <code>skip_docformatter</code>
<span style="color: purple">type: <code>bool</code></span>
<span style="color: green">default: <code>False</code></span>
backend: <span style="color: green"><code>pants.backend.python.lint.docformatter</code></span>
If true, don't run Docformatter on this target's code.
## <code>skip_flake8</code>
<span style="color: purple">type: <code>bool</code></span>
<span style="color: green">default: <code>False</code></span>
backend: <span style="color: green"><code>pants.backend.python.lint.flake8</code></span>
If true, don't run Flake8 on this target's code.
## <code>skip_isort</code>
<span style="color: purple">type: <code>bool</code></span>
<span style="color: green">default: <code>False</code></span>
backend: <span style="color: green"><code>pants.backend.python.lint.isort</code></span>
If true, don't run isort on this target's code.
## <code>skip_mypy</code>
<span style="color: purple">type: <code>bool</code></span>
<span style="color: green">default: <code>False</code></span>
backend: <span style="color: green"><code>pants.backend.python.typecheck.mypy</code></span>
If true, don't run MyPy on this target's code.
## <code>skip_pylint</code>
<span style="color: purple">type: <code>bool</code></span>
<span style="color: green">default: <code>False</code></span>
backend: <span style="color: green"><code>pants.backend.python.lint.pylint</code></span>
If true, don't run Pylint on this target's code.
## <code>skip_pyupgrade</code>
<span style="color: purple">type: <code>bool</code></span>
<span style="color: green">default: <code>False</code></span>
backend: <span style="color: green"><code>pants.backend.experimental.python.lint.pyupgrade</code></span>
If true, don't run pyupgrade on this target's code.
## <code>skip_yapf</code>
<span style="color: purple">type: <code>bool</code></span>
<span style="color: green">default: <code>False</code></span>
backend: <span style="color: green"><code>pants.backend.python.lint.yapf</code></span>
If true, don't run yapf on this target's code.
## <code>sources</code>
<span style="color: purple">type: <code>Iterable[str] | None</code></span>
<span style="color: green">default: <code>('*.py', '*.pyi', '!test_*.py', '!*_test.py', '!tests.py', '!conftest.py', '!test_*.pyi', '!*_test.pyi', '!tests.pyi')</code></span>
A list of files and globs that belong to this target.
Paths are relative to the BUILD file's directory. You can ignore files/globs by prefixing them with `!`.
Example: `sources=['example.py', 'new_*.py', '!old_ignore.py']`
## <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.