| commit | a3cdab5e2670792d5c31b28606722fe11b8d4356 | [log] [tgz] |
|---|---|---|
| author | Richard Levasseur <rlevasseur@google.com> | Fri Oct 11 11:25:34 2024 -0700 |
| committer | GitHub <noreply@github.com> | Fri Oct 11 18:25:34 2024 +0000 |
| tree | 2b27d70e8e87fda5c70384a4c884da3609ba3cf1 | |
| parent | f6361e4dc33f841ecd526f0dc16797a52f451e8c [diff] |
fix(precompiling)!: make binary-level precompile opt-in/opt-opt work (#2243) This makes binary-level opt-in/opt-out of precompiling work as intended. Previously, when `pyc_collection=include_pyc` was set on a binary, only transitive libraries that had explicitly enabled precompiling were being included (which was moot anyways -- libraries put their files in runfiles, so no matter what, their files were included). The intent was that, when a binary set `pyc_collection=include_pyc`, then precompiled files would be used for all its transitive dependencies (unless they had, at the target-level, disabled precompiling). Conversely, if `pyc_collection=disabled` was set, the precompiled files would not be used (unless a target had, at the target level, enabled precompiling). To make it work as desired, the basic fix is to make it so that libraries have a place to put the implicit pyc files (the ones automatically generated), and have the binaries include those when requested. The net effect is a library has 4 sets of files it produces: * required py files: py source files that should always go into the binary's runfiles * required pyc files: precompiled pyc files that should always go into the binary's runfiles (e.g., when a library sets `precompile=enabled` directly). * implicit pyc files: precompiled pyc files for a library that are always generated, but it's up to the binary if they go into the runfiles * implicit pyc source files: the source py file for an implicit pyc file. When a binary *doesn't* include the implicit pyc file, it must include the source py file (otherwise none of the library's code ends up included). Similarly, in order to allow a binary to decide what files are used, libraries must stop putting the py/pyc files into runfiles themselves. While this is potentially a breaking change, I found that, within Google, there was no reliance on this behavior, so should be safe enough. That said, I added `--add_srcs_to_runfiles` to restore the previous behavior to aid in transitioning. **BREAKING CHANGES** 1. `py_library` no longer puts its srcs into runfiles directly. 2. Removed `--precompile_add_to_runfiles` 3. Removed `--pyc_collection` 4. `precompile=if_generated_source` removed 5. `precompile_source_retention=omit_if_generated_source` removed Though 2 through 5 are technically breaking changes, I don't think precompiling was very usable anyways, so usages of those flags/values is rare. Fixes https://github.com/bazelbuild/rules_python/issues/2212
This repository is the home of the core Python rules -- py_library, py_binary, py_test, py_proto_library, and related symbols that provide the basis for Python support in Bazel. It also contains package installation rules for integrating with PyPI and other indices.
Documentation for rules_python is at https://rules-python.readthedocs.io and in the Bazel Build Encyclopedia.
Examples live in the examples directory.
The core rules are stable. Their implementation is subject to Bazel's backward compatibility policy. This repository aims to follow semantic versioning.
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 How to contribute page for information on our development workflow.
For detailed documentation, see https://rules-python.readthedocs.io
See Bzlmod support for more details.