| # Python Rules for Bazel | |
| `rules_python` is the home for four major components with varying maturity levels. | |
| :::{topic} Core rules | |
| The core Python rules -- `py_library`, `py_binary`, `py_test`, | |
| and related symbols that provide the basis for Python | |
| support in Bazel. | |
| When using Bazel 6 (or earlier), the core rules are bundled into the Bazel binary, and the symbols | |
| in this repository are simple aliases. On Bazel 7 and above, `rules_python` uses | |
| a separate Starlark implementation; | |
| see {ref}`Migrating from the Bundled Rules` below. | |
| This repository follows | |
| [semantic versioning](https://semver.org) and the breaking change policy | |
| outlined in the [support](support) page. | |
| ::: | |
| :::{topic} PyPI integration | |
| Package installation rules for integrating with PyPI and other Simple API- | |
| compatible indexes. | |
| These rules work and can be used in production, but the cross-platform building | |
| that supports pulling PyPI dependencies for a target platform that is different | |
| from the host platform is still in beta, and the APIs that are subject to potential | |
| change are marked as `experimental`. | |
| ::: | |
| :::{topic} Sphinxdocs | |
| `sphinxdocs` rules allow users to generate documentation using Sphinx powered by Bazel, with additional functionality for documenting | |
| Starlark and Bazel code. | |
| The functionality is exposed because other projects find it useful, but | |
| it is available "as is", and **the semantic versioning and | |
| compatibility policy used by `rules_python` does not apply**. | |
| ::: | |
| :::{topic} Gazelle plugin | |
| `gazelle` plugin for generating `BUILD.bazel` files based on Python source | |
| code. | |
| This is available "as is", and the semantic versioning used by `rules_python` does | |
| not apply. | |
| ::: | |
| The Bazel community maintains this repository. Neither Google nor the Bazel | |
| team provides support for the code. However, this repository is part of the | |
| test suite used to vet new Bazel releases. See {gh-path}`How to contribute | |
| <CONTRIBUTING.md>` for information on our development workflow. | |
| ## Examples | |
| This documentation is an example of `sphinxdocs` rules and the rest of the | |
| components have examples in the {gh-path}`examples` directory. | |
| ## Migrating from the bundled rules | |
| The core rules are currently available in Bazel as built-in symbols, but this | |
| form is deprecated. Instead, you should depend on rules_python in your | |
| `WORKSPACE` or `MODULE.bazel` file and load the Python rules from | |
| `@rules_python//python:<name>.bzl` or load paths described in the API documentation. | |
| A [buildifier](https://github.com/bazelbuild/buildtools/blob/master/buildifier/README.md) | |
| fix is available to automatically migrate `BUILD` and `.bzl` files to add the | |
| appropriate `load()` statements and rewrite uses of `native.py_*`. | |
| ```sh | |
| # Also consider using the -r flag to modify an entire workspace. | |
| buildifier --lint=fix --warnings=native-py <files> | |
| ``` | |
| Currently, the `WORKSPACE` file needs to be updated manually as per | |
| [Getting started](getting-started). | |
| Note that Starlark-defined bundled symbols underneath | |
| `@bazel_tools//tools/python` are also deprecated. These are not yet rewritten | |
| by buildifier. | |
| ## Migrating to bzlmod | |
| See {gh-path}`Bzlmod support <BZLMOD_SUPPORT.md>` for any behavioral differences between | |
| `bzlmod` and `WORKSPACE`. | |
| ```{toctree} | |
| :hidden: | |
| self | |
| getting-started | |
| pypi/index | |
| Toolchains <toolchains> | |
| coverage | |
| precompiling | |
| gazelle/docs/index | |
| REPL <repl> | |
| Extending <extending> | |
| How-to Guides <howto/index> | |
| Contributing <contributing> | |
| devguide | |
| support | |
| Changelog <changelog> | |
| api/index | |
| environment-variables | |
| Sphinxdocs <sphinxdocs/index> | |
| glossary | |
| genindex | |
| ``` |