third_party/xla/third_party/py/README.md
Provides a standardized and efficient system for packaging and verifying ML software.
Standardized creation, validation (auditwheel) and testing of wheel
artifacts.
Availability of the final wheel artifacts in the Bazel Build phase, which
enables testing of generated wheels by regular py_test targets
together with the rest of the existing tests.
Ability to use Bazel RBE for wheel creation and testing.
Reproducible and unified steps for generating testing of the wheels on different platforms.
Integrate hermetic Python, C++ and CUDA (if needed) toolchains in the project.
Examples:
JAX hermetic Python and C++ integration
Create python script that produces a wheel, and declare it as py_binary
build rule.
A common case scenario: a python script should take wheel sources provided in
the arguments list, then do the required transformations and run command like
python -m build in the folder with the collected resources.
Create Bazel build rule that returns python wheel in the output.
In a common case scenario, this Bazel rule runs py_binary (created in
step 1) passed in the rule attributes.
The wheel sources should be provided in the wheel build rule attributes.
To collect the wheel sources that are suitable for all types of Bazel
builds, including cross-compile builds, the following build rules should be
used: collect_data_files, transitive_py_deps from
@xla//third_party/py:python_wheel.bzl, and transitive_hdrs from
@xla//xla/tsl:tsl.bzl.
the wheel name should conform to PEP-491 naming convention.
Storing of the wheel version is custom, and should be implemented per project. It can be additional repository rule, or a constant in .bzl file.
The wheel suffix is controlled by a common repository rule
python_wheel_version_suffix_repository, that should be called in
WORKSPACE file.
To verify manylinux tag compliance, use common py_binary
verify_manylinux_compliance_test.
py_import call. py_import target can be used in other python targets in
the same way as py_library.