python

Options for Pants's Python backend.
Backend: <span style="color: purple"><code>pants.core</code></span>
Config section: <span style="color: purple"><code>[python]</code></span>
## Basic options
<div style="color: purple">
### `default_run_goal_use_sandbox`
  <code>--[no-]python-default-run-goal-use-sandbox</code><br>
  <code>PANTS_PYTHON_DEFAULT_RUN_GOAL_USE_SANDBOX</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>True</code></span>
<br>
The default value used for the `run_goal_use_sandbox` field of Python targets. See the relevant field for more details.
</div>
<br>
## Advanced options
<div style="color: purple">
### `interpreter_constraints`
  <code>--python-interpreter-constraints="[&lt;requirement&gt;, &lt;requirement&gt;, ...]"</code><br>
  <code>PANTS_PYTHON_INTERPRETER_CONSTRAINTS</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <pre>[
  "CPython&gt;=3.7,&lt;4"
]</pre></span>
<br>
The Python interpreters your codebase is compatible with.
These constraints are used as the default value for the `interpreter_constraints` field of Python targets.
Specify with requirement syntax, e.g. 'CPython>=2.7,<3' (A CPython interpreter with version >=2.7 AND version <3) or 'PyPy' (A pypy interpreter of any version). Multiple constraint strings will be ORed together.
</div>
<br>
<div style="color: purple">
### `interpreter_versions_universe`
  <code>--python-interpreter-versions-universe="['&lt;str&gt;', '&lt;str&gt;', ...]"</code><br>
  <code>PANTS_PYTHON_INTERPRETER_VERSIONS_UNIVERSE</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <pre>[
  "2.7",
  "3.5",
  "3.6",
  "3.7",
  "3.8",
  "3.9",
  "3.10",
  "3.11"
]</pre></span>
<br>
All known Python major/minor interpreter versions that may be used by either your code or tools used by your code.
This is used by Pants to robustly handle interpreter constraints, such as knowing when generating lockfiles which Python versions to check if your code is using.
This does not control which interpreter your code will use. Instead, to set your interpreter constraints, update `[python].interpreter_constraints`, the `interpreter_constraints` field, and relevant tool options like `[isort].interpreter_constraints` to tell Pants which interpreters your code actually uses. See [Interpreter compatibility](🔗﻿).
All elements must be the minor and major Python version, e.g. '2.7' or '3.10'. Do not include the patch version.
</div>
<br>
<div style="color: purple">
### `enable_resolves`
  <code>--[no-]python-enable-resolves</code><br>
  <code>PANTS_PYTHON_ENABLE_RESOLVES</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>False</code></span>
<br>
Set to true to enable lockfiles for user code. See `[python].resolves` for an explanation of this feature.
Warning: the `generate-lockfiles` goal does not yet work if you have local requirements, regardless of using Pex vs. Poetry for the lockfile generator. Support is coming in a future Pants release. In the meantime, the workaround is to host the files in a custom repository with `[python-repos]` ([Third-party dependencies](🔗﻿)).
You may also run into issues generating lockfiles when using Poetry as the generator, rather than Pex. See the option `[python].lockfile_generator` for more information.
This option is mutually exclusive with `[python].requirement_constraints`. We strongly recommend using this option because it:
Uses `--hash` to validate that all downloaded files are expected, which reduces the risk of supply chain attacks.
Enforces that all transitive dependencies are in the lockfile, whereas constraints allow you to leave off dependencies. This ensures your build is more stable and reduces the risk of supply chain attacks.
Allows you to have multiple lockfiles in your repository.
</div>
<br>
<div style="color: purple">
### `resolves`
  <code>--python-resolves="{'key1': val1, 'key2': val2, ...}"</code><br>
  <code>PANTS_PYTHON_RESOLVES</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <pre>{
  "python-default": "3rdparty/python/default.lock"
}</pre></span>
<br>
A mapping of logical names to lockfile paths used in your project.
Many organizations only need a single resolve for their whole project, which is a good default and often the simplest thing to do. However, you may need multiple resolves, such as if you use two conflicting versions of a requirement in your repository.
If you only need a single resolve, run `./pants generate-lockfiles` to generate the lockfile.
If you need multiple resolves:
Via this option, define multiple resolve names and their lockfile paths. The names should be meaningful to your repository, such as `data-science` or `pants-plugins`.
Set the default with `[python].default_resolve`.
Update your `python_requirement` targets with the `resolve` field to declare which resolve they should be available in. They default to `[python].default_resolve`, so you only need to update targets that you want in non-default resolves. (Often you'll set this via the `python_requirements` or `poetry_requirements` target generators)
Run `./pants generate-lockfiles` to generate the lockfiles. If the results aren't what you'd expect, adjust the prior step.
Update any targets like `python_source` / `python_sources`, `python_test` / `python_tests`, and `pex_binary` which need to set a non-default resolve with the `resolve` field.
If a target can work with multiple resolves, you can either use the `parametrize` mechanism or manually create a distinct target per resolve. See [Targets and BUILD files](🔗﻿) for information about `parametrize`.
For example:
﻿
You can name the lockfile paths what you would like; Pants does not expect a certain file extension or location.
Only applies if `[python].enable_resolves` is true.
</div>
<br>
<div style="color: purple">
### `default_resolve`
  <code>--python-default-resolve=<str></code><br>
  <code>PANTS_PYTHON_DEFAULT_RESOLVE</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>python-default</code></span>
<br>
The default value used for the `resolve` field.
The name must be defined as a resolve in `[python].resolves`.
</div>
<br>
<div style="color: purple">
### `resolves_to_interpreter_constraints`
  <code>--python-resolves-to-interpreter-constraints="{'key1': val1, 'key2': val2, ...}"</code><br>
  <code>PANTS_PYTHON_RESOLVES_TO_INTERPRETER_CONSTRAINTS</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>{}</code></span>
<br>
Override the interpreter constraints to use when generating a resolve's lockfile with the `generate-lockfiles` goal.
By default, each resolve from `[python].resolves` will use your global interpreter constraints set in `[python].interpreter_constraints`. With this option, you can override each resolve to use certain interpreter constraints, such as `{'data-science': ['==3.8.*']}`.
Warning: this does NOT impact the interpreter constraints used by targets within the resolve, which is instead set by the option `[python.interpreter_constraints` and the `interpreter_constraints` field. It only impacts how the lockfile is generated.
Pants will validate that the interpreter constraints of your code using a resolve are compatible with that resolve's own constraints. For example, if your code is set to use ['==3.9.*'] via the `interpreter_constraints` field, but it's using a resolve whose interpreter constraints are set to ['==3.7.*'], then Pants will error explaining the incompatibility.
The keys must be defined as resolves in `[python].resolves`. To change the interpreter constraints for tool lockfiles, change `[tool].interpreter_constraints`, e.g. `[black].interpreter_constraints`; if the tool does not have that option, it determines its interpreter constraints from your user code.
</div>
<br>
<div style="color: purple">
### `resolves_to_constraints_file`
  <code>--python-resolves-to-constraints-file="{'key1': val1, 'key2': val2, ...}"</code><br>
  <code>PANTS_PYTHON_RESOLVES_TO_CONSTRAINTS_FILE</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>{}</code></span>
<br>
When generating a resolve's lockfile, use a constraints file to pin the version of certain requirements. This is particularly useful to pin the versions of transitive dependencies of your direct requirements.
See https://pip.pypa.io/en/stable/user_guide/#constraints-files for more information on the format of constraint files and how constraints are applied in Pex and pip.
Expects a dictionary of resolve names from `[python].resolves` and Python tools (e.g. `black` and `pytest`) to file paths for constraints files. For example, `{'data-science': '3rdparty/data-science-constraints.txt'}`. If a resolve is not set in the dictionary, it will not use a constraints file.
You can use the key `__default__` to set a default value for all resolves.
Note: Only takes effect if you use Pex lockfiles. Use the default `[python].lockfile_generator = "pex"` and run the `generate-lockfiles` goal.
</div>
<br>
<div style="color: purple">
### `resolves_to_no_binary`
  <code>--python-resolves-to-no-binary="{'key1': val1, 'key2': val2, ...}"</code><br>
  <code>PANTS_PYTHON_RESOLVES_TO_NO_BINARY</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>{}</code></span>
<br>
When generating a resolve's lockfile, do not use binary packages (i.e. wheels) for these 3rdparty project names.
Expects a dictionary of resolve names from `[python].resolves` and Python tools (e.g. `black` and `pytest`) to lists of project names. For example, `{'data-science': ['requests', 'numpy']}`. If a resolve is not set in the dictionary, it will have no restrictions on binary packages.
You can use the key `__default__` to set a default value for all resolves.
For each resolve's value, you can use the value `:all:` to disable all binary packages.
Note that some packages are tricky to compile and may fail to install when this option is used on them. See https://pip.pypa.io/en/stable/cli/pip_install/#install-no-binary for details.
Note: Only takes effect if you use Pex lockfiles. Use the default `[python].lockfile_generator = "pex"` and run the `generate-lockfiles` goal.
</div>
<br>
<div style="color: purple">
### `resolves_to_only_binary`
  <code>--python-resolves-to-only-binary="{'key1': val1, 'key2': val2, ...}"</code><br>
  <code>PANTS_PYTHON_RESOLVES_TO_ONLY_BINARY</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>{}</code></span>
<br>
When generating a resolve's lockfile, do not use source packages (i.e. sdists) for these 3rdparty project names, e.g `['django', 'requests']`.
Expects a dictionary of resolve names from `[python].resolves` and Python tools (e.g. `black` and `pytest`) to lists of project names. For example, `{'data-science': ['requests', 'numpy']}`. If a resolve is not set in the dictionary, it will have no restrictions on source packages.
You can use the key `__default__` to set a default value for all resolves.
For each resolve's value, you can use the value `:all:` to disable all source packages.
Packages without binary distributions will fail to install when this option is used on them. See https://pip.pypa.io/en/stable/cli/pip_install/#install-only-binary for details.
Note: Only takes effect if you use Pex lockfiles. Use the default `[python].lockfile_generator = "pex"` and run the `generate-lockfiles` goal.
</div>
<br>
<div style="color: purple">
### `invalid_lockfile_behavior`
  <code>--python-invalid-lockfile-behavior=<InvalidLockfileBehavior></code><br>
  <code>PANTS_PYTHON_INVALID_LOCKFILE_BEHAVIOR</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">one of: <code>error, ignore, warn</code></span><br>
<span style="color: green">default: <code>error</code></span>
<br>
The behavior when a lockfile has requirements or interpreter constraints that are not compatible with what the current build is using.
We recommend keeping the default of `error` for CI builds.
Note that `warn` will still expect a Pants lockfile header, it only won't error if the lockfile is stale and should be regenerated.
Use `ignore` to avoid needing a lockfile header at all, e.g. if you are manually managing lockfiles rather than using the `generate-lockfiles` goal.
</div>
<br>
<div style="color: purple">
### `resolves_generate_lockfiles`
  <code>--[no-]python-resolves-generate-lockfiles</code><br>
  <code>PANTS_PYTHON_RESOLVES_GENERATE_LOCKFILES</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>True</code></span>
<br>
If False, Pants will not attempt to generate lockfiles for `[python].resolves` when running the `generate-lockfiles` goal.
This is intended to allow you to manually generate lockfiles for your own code, rather than using Pex lockfiles. For example, when adopting Pants in a project already using Poetry, you can use `poetry export --dev` to create a requirements.txt-style lockfile understood by Pants, then point `[python].resolves` to the file.
If you set this to False, Pants will not attempt to validate the metadata headers for your user lockfiles. This is useful so that you can keep `[python].invalid_lockfile_behavior` to `error` or `warn` if you'd like so that tool lockfiles continue to be validated, while user lockfiles are skipped.
Warning: it will likely be slower to install manually generated user lockfiles than Pex ones because Pants cannot as efficiently extract the subset of requirements used for a particular task. See the option `[python].run_against_entire_lockfile`.
</div>
<br>
<div style="color: purple">
### `run_against_entire_lockfile`
  <code>--[no-]python-run-against-entire-lockfile</code><br>
  <code>PANTS_PYTHON_RUN_AGAINST_ENTIRE_LOCKFILE</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>False</code></span>
<br>
If enabled, when running binaries, tests, and repls, Pants will use the entire lockfile file instead of just the relevant subset.
If you are using Pex lockfiles, we generally do not recommend this. You will already get similar performance benefits to this option, without the downsides.
Otherwise, this option can improve performance and reduce cache size. But it has two consequences: 1) All cached test results will be invalidated if any requirement in the lockfile changes, rather than just those that depend on the changed requirement. 2) Requirements unneeded by a test/run/repl will be present on the sys.path, which might in rare cases cause their behavior to change.
This option does not affect packaging deployable artifacts, such as PEX files, wheels and cloud functions, which will still use just the exact subset of requirements needed.
</div>
<br>
<div style="color: purple">
### `resolver_manylinux`
  <code>--python-resolver-manylinux=<str></code><br>
  <code>PANTS_PYTHON_RESOLVER_MANYLINUX</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>manylinux2014</code></span>
<br>
Whether to allow resolution of manylinux wheels when resolving requirements for foreign linux platforms. The value should be a manylinux platform upper bound, e.g.: 'manylinux2010', or else the string 'no' to disallow.
</div>
<br>
<div style="color: purple">
### `tailor_source_targets`
  <code>--[no-]python-tailor-source-targets</code><br>
  <code>PANTS_PYTHON_TAILOR_SOURCE_TARGETS</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>True</code></span>
<br>
If true, add `python_sources`, `python_tests`, and `python_test_utils` targets with the `tailor` goal.
</div>
<br>
<div style="color: purple">
### `tailor_ignore_empty_init_files`
  <code>--[no-]python-tailor-ignore-empty-init-files</code><br>
  <code>PANTS_PYTHON_TAILOR_IGNORE_EMPTY_INIT_FILES</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>True</code></span>
<br>
If true, don't add `python_sources` targets for `__init__.py` files that are both empty and where there are no other Python files in the directory.
Empty and solitary `__init__.py` files usually exist as import scaffolding rather than true library code, so it can be noisy to add BUILD files.
Even if this option is set to true, Pants will still ensure the empty `__init__.py` files are included in the sandbox when running processes.
If you set to false, you may also want to set `[python-infer].init_files = "always"`.
</div>
<br>
<div style="color: purple">
### `tailor_requirements_targets`
  <code>--[no-]python-tailor-requirements-targets</code><br>
  <code>PANTS_PYTHON_TAILOR_REQUIREMENTS_TARGETS</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>True</code></span>
<br>
If true, add `python_requirements`, `poetry_requirements`, and `pipenv_requirements` target generators with the `tailor` goal.
`python_requirements` targets are added for any file that matches the pattern `*requirements*.txt`. You will need to manually add `python_requirements` for different file names like `reqs.txt`.
`poetry_requirements` targets are added for `pyproject.toml` files with `[tool.poetry` in them.
</div>
<br>
<div style="color: purple">
### `tailor_pex_binary_targets`
  <code>--[no-]python-tailor-pex-binary-targets</code><br>
  <code>PANTS_PYTHON_TAILOR_PEX_BINARY_TARGETS</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>False</code></span>
<br>
If true, add `pex_binary` targets for Python files named `__main__.py` or with a `__main__` clause with the `tailor` goal.
</div>
<br>
<div style="color: purple">
### `macos_big_sur_compatibility`
  <code>--[no-]python-macos-big-sur-compatibility</code><br>
  <code>PANTS_PYTHON_MACOS_BIG_SUR_COMPATIBILITY</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>False</code></span>
<br>
If set, and if running on MacOS Big Sur, use macosx_10_16 as the platform when building wheels. Otherwise, the default of macosx_11_0 will be used. This may be required for pip to be able to install the resulting distribution on Big Sur.
</div>
<br>
## Deprecated options
<div style="color: purple">
### `lockfile_generator`
  <code>--python-lockfile-generator=<LockfileGenerator></code><br>
  <code>PANTS_PYTHON_LOCKFILE_GENERATOR</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">one of: <code>pex, poetry</code></span><br>
<span style="color: green">default: <code>pex</code></span>
<p style="color: darkred">Deprecated, is scheduled to be removed in version: 2.15.0.dev0.<br>Pants will soon only support generating lockfiles via the Pex format, as Poetry-generated lockfiles mismatch with Pants's pip-based approach.
If you do not want to use Pex lockfiles, you will still be able to manually generate lockfiles, e.g. by manually running `poetry export --dev` on your `poetry.lock`. See [Third-party dependencies](🔗﻿) for more information.
While Pex generates locks in a proprietary JSON format, you can use the `./pants export` goal for Pants to create a virtual environment for interoperability with tools like IDEs.
Please open a GitHub issue or reach out on Slack if you encounter issues while migrating: [Getting help](🔗﻿)﻿
Tip: you can incrementally migrate one lockfile at-a-time by dynamically setting the option `--python-lockfile-generator`. For example:
  ./pants --python-lockfile-generator=pex generate-lockfiles --resolve=black --resolve=isort
  ./pants --python-lockfile-generator=poetry generate-lockfiles --resolve=python-default</p>
<br>
Whether to use Pex or Poetry with the `generate-lockfiles` goal.
Poetry does not support these features:
`[python-repos]` for custom indexes/cheeseshops.
VCS (Git) requirements.
`[GLOBAL].ca_certs_path`.
If you use any of these features, you should use Pex.
Several users have also had issues with how Poetry's lockfile generation handles environment markers for transitive dependencies; certain dependencies end up with nonsensical environment markers which cause the dependency to not be installed, then for Pants/Pex to complain the dependency is missing, even though it's in the lockfile. There is a workaround: for `[python].resolves`, manually create a `python_requirement` target for the problematic transitive dependencies so that they are seen as direct requirements, rather than transitive. For tool lockfiles, add the problematic transitive dependency to `[tool].extra_requirements`, e.g. `[isort].extra_requirements`. Then, regenerate the lockfile(s) with the `generate-lockfiles` goal. Alternatively, use Pex for generation.
Finally, installing from a Poetry-generated lockfile is slower than installing from a Pex lockfile. When using a Pex lockfile, Pants will only install the subset needed for the current task.
However, Pex lockfile generation is a new feature. Given how vast the Python packaging ecosystem is, it is possible you may experience edge cases / bugs we haven't yet covered. Bug reports are appreciated! https://github.com/pantsbuild/pants/issues/new/choose
Note that while Pex generates locks in a proprietary JSON format, you can use the `./pants export` goal for Pants to create a virtual environment for interoperability with tools like IDEs.
</div>
<br>
<div style="color: purple">
### `requirement_constraints`
  <code>--python-requirement-constraints=<file_option></code><br>
  <code>PANTS_PYTHON_REQUIREMENT_CONSTRAINTS</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>None</code></span>
<p style="color: darkred">Deprecated, is scheduled to be removed in version: 3.0.0.dev0.<br>We encourage instead migrating to `[python].enable_resolves` and `[python].resolves`, which is an improvement over this option. The `[python].resolves` feature ensures that your lockfiles are fully comprehensive, i.e. include all transitive dependencies; uses hashes for better supply chain security; and supports advanced features like VCS and local requirements, along with options `[python].resolves_to_only_binary`.
To migrate, stop setting `[python].requirement_constraints` and `[python].resolve_all_constraints`, and instead set `[python].enable_resolves` to `true`. Then, run `./pants generate-lockfiles`.</p>
<br>
When resolving third-party requirements for your own code (vs. tools you run), use this constraints file to determine which versions to use.
Mutually exclusive with `[python].enable_resolves`, which we generally recommend as an improvement over constraints file.
See https://pip.pypa.io/en/stable/user_guide/#constraints-files for more information on the format of constraint files and how constraints are applied in Pex and pip.
This only applies when resolving user requirements, rather than tools you run like Black and Pytest. To constrain tools, set `[tool].lockfile`, e.g. `[black].lockfile`.
</div>
<br>
<div style="color: purple">
### `resolve_all_constraints`
  <code>--[no-]python-resolve-all-constraints</code><br>
  <code>PANTS_PYTHON_RESOLVE_ALL_CONSTRAINTS</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>True</code></span>
<p style="color: darkred">Deprecated, is scheduled to be removed in version: 3.0.0.dev0.<br>We encourage instead migrating to `[python].enable_resolves` and `[python].resolves`, which is an improvement over this option. The `[python].resolves` feature ensures that your lockfiles are fully comprehensive, i.e. include all transitive dependencies; uses hashes for better supply chain security; and supports advanced features like VCS and local requirements, along with options `[python].resolves_to_only_binary`.
To migrate, stop setting `[python].requirement_constraints` and `[python].resolve_all_constraints`, and instead set `[python].enable_resolves` to `true`. Then, run `./pants generate-lockfiles`.</p>
<br>
(Only relevant when using `[python].requirement_constraints.`) If enabled, when resolving requirements, Pants will first resolve your entire constraints file as a single global resolve. Then, if the code uses a subset of your constraints file, Pants will extract the relevant requirements from that global resolve so that only what's actually needed gets used. If disabled, Pants will not use a global resolve and will resolve each subset of your requirements independently.
Usually this option should be enabled because it can result in far fewer resolves.
</div>
<br>
<div style="color: purple">
### `no_binary`
  <code>--python-no-binary="['&lt;str&gt;', '&lt;str&gt;', ...]"</code><br>
  <code>PANTS_PYTHON_NO_BINARY</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>[]</code></span>
<p style="color: darkred">Deprecated, is scheduled to be removed in version: 2.15.0.dev0.<br>Use `[python].resolves_to_no_binary`, which allows you to set `--no-binary` on a per-resolve basis for more flexibility. To keep this option's behavior, set `[python].resolves_to_no_binary` with the key `__default__` and the value you used on this option.</p>
<br>
Do not use binary packages (i.e., wheels) for these 3rdparty projects.
Also accepts `:all:` to disable all binary packages.
Note that some packages are tricky to compile and may fail to install when this option is used on them. See https://pip.pypa.io/en/stable/cli/pip_install/#install-no-binary for details.
Note: Only takes effect if you use Pex lockfiles. Use the default `[python].lockfile_generator = "pex"` and run the `generate-lockfiles` goal.
</div>
<br>
<div style="color: purple">
### `only_binary`
  <code>--python-only-binary="['&lt;str&gt;', '&lt;str&gt;', ...]"</code><br>
  <code>PANTS_PYTHON_ONLY_BINARY</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>[]</code></span>
<p style="color: darkred">Deprecated, is scheduled to be removed in version: 2.15.0.dev0.<br>Use `[python].resolves_to_only_binary`, which allows you to set `--only-binary` on a per-resolve basis for more flexibility. To keep this option's behavior, set `[python].resolves_to_only_binary` with the key `__default__` and the value you used on this option.</p>
<br>
Do not use source packages (i.e., sdists) for these 3rdparty projects.
Also accepts `:all:` to disable all source packages.
Packages without binary distributions will fail to install when this option is used on them. See https://pip.pypa.io/en/stable/cli/pip_install/#install-only-binary for details.
Note: Only takes effect if you use Pex lockfiles. Use the default `[python].lockfile_generator = "pex"` and run the `generate-lockfiles` goal.
</div>
<br>
<div style="color: purple">
### `tailor_ignore_solitary_init_files`
  <code>--[no-]python-tailor-ignore-solitary-init-files</code><br>
  <code>PANTS_PYTHON_TAILOR_IGNORE_SOLITARY_INIT_FILES</code><br>
</div>
<div style="padding-left: 2em;">
<span style="color: green">default: <code>True</code></span>
<p style="color: darkred">Deprecated, is scheduled to be removed in version: 2.15.0.dev0.<br>Use `[python].tailor_ignore_empty_init_files`, which checks that the `__init__.py`file is both solitary and also empty.</p>
<br>
If true, don't add `python_sources` targets for solitary `__init__.py` files with the `tailor` goal.
Solitary `__init__.py` files usually exist as import scaffolding rather than true library code, so it can be noisy to add BUILD files.
Set to false if you commonly have packages containing real code in `__init__.py` without other `.py` files in the package.
</div>
<br>
## Basic options

### ``default_run_goal_use_sandbox``

## Advanced options

### ``interpreter_constraints``

### ``interpreter_versions_universe``

### ``enable_resolves``

### ``resolves``

### ``default_resolve``

### ``resolves_to_interpreter_constraints``

### ``resolves_to_constraints_file``

### ``resolves_to_no_binary``

### ``resolves_to_only_binary``

### ``invalid_lockfile_behavior``

### ``resolves_generate_lockfiles``

### ``run_against_entire_lockfile``

### ``resolver_manylinux``

### ``tailor_source_targets``

### ``tailor_ignore_empty_init_files``

### ``tailor_requirements_targets``

### ``tailor_pex_binary_targets``

### ``macos_big_sur_compatibility``

## Deprecated options

### ``lockfile_generator``

### ``requirement_constraints``

### ``resolve_all_constraints``

### ``no_binary``

### ``only_binary``

### ``tailor_ignore_solitary_init_files``
