Lines Matching refs:Python
4 # Configuring Python toolchains and runtimes
6 This documents how to configure the Python toolchain and runtimes for different
12 you're using Python. There are 4 basic use cases:
14 1. A root module that always uses Python. For example, you're building a
15 Python application.
16 2. A library module with dev-only uses of Python. For example, a Java project
17 that only uses Python as part of testing itself.
19 Python build tools, but defers to the user as to what Python version is used
22 Python build tools, and the module requires a specific version of Python
34 explicitly specify the Python version you want to use. This ensures that
35 dependencies don't change the Python version out from under you. Remember that
37 it tracks a recent Python version.
39 NOTE: If your root module only uses Python for development of the module itself,
56 #### Library modules with dev-only Python usage
58 A library module with dev-only Python usage is usually one where Python is only
60 Python program to generate test data, but real usage of the rules don't need
61 Python to work. To configure this, follow the root-module setup, but remember to
79 A library module without version constraints is one where the version of Python
80 used for the Python programs it runs isn't chosen by the module itself. Instead,
81 it's up to the root module to pick an appropriate version of Python.
85 `python.toolchain` -- rules_python ensures _some_ Python version is available,
96 specific Python version be used with its tools. This has some pros/cons:
98 * It allows the library's tools to use a different version of Python than
99 the rest of the build. For example, a user's program could use Python 3.12,
100 while the library module's tools use Python 3.10.
102 to test for the particular Python version they intend to run as.
104 Python being used needs to be regularly incremented.
108 To configure this, request the Python versions needed in MODULE.bazel and use
124 ### Pinning to a Python version
126 Pinning to a version allows targets to force that a specific Python version is
130 1. For submodules to ensure they run with the appropriate Python version
131 2. To allow incremental, per-target, upgrading to newer Python versions,
164 Python toolchains can be utilized in other bazel rules, such as `genrule()`, by
166 attribute. You can obtain the path to the Python interpreter using the
180 * Setting particular `X.Y.Z` Python versions when modules request `X.Y` version
184 * Adding additional Python versions via {bzl:obj}`python.single_version_override` or
220 To register a hermetic Python toolchain rather than rely on a system-installed interpreter for runt…
243 After registration, your Python targets will use the toolchain's interpreter during execution, but …
244 is still used to 'bootstrap' Python targets (see https://github.com/bazelbuild/rules_python/issues/…
253 the Python runtime).
278 information necessary to build Python targets. Each one has an
284 {obj}`RBE`, cross-platform building, multiple Python versions,
285 building Python from source, embeding Python (as opposed to building separate
293 is for _target configuration_ runtime information, e.g., the Python version
298 Python 2 transition, `py_runtime` is wrapped in {obj}`py_runtime_pair`,
308 ### Python C toolchain type
310 The Python C toolchain type ("py cc") is {obj}`//python/cc:toolchain_type`, and
312 provide `Python.h`.
319 relating to the C/C++ information for the Python runtime. As such, when defining
332 usually tools (prebuilt or from-source) used to build Python targets.
340 {external:bzl:obj}`toolchain.target_settings` to the Python version the tools
343 target configuration (e.g. Python version), then for one to be chosen based on
349 * If you had a precompiler that supported any version of Python, then
350 putting the Python version in `target_settings` is unnecessary.
367 * For Python version 3.12.0