Repository navigation
feat(rules): describe runfiles groups for rules_runfiles_group - #4254
Open
FrankPortman wants to merge 6 commits into
Open
FrankPortman wants to merge 6 commits into
FrankPortman wants to merge 6 commits into
Conversation
Give py_library, py_binary and py_test runfiles group describers, so packaging rules that use rules_runfiles_group (e.g. rules_img's image_from_binary) can split a binary's runfiles into layers: the runtime, one group per PyPI package, one per library and per rule target in data, and the binary's own files. Groups are collected on demand by a packager's aspect, so nothing runs otherwise. The runtime group comes from a singleton target resolving the same toolchain as the binary, so a packager builds it once per configuration. A binary whose pyc_collection differs from the configuration's, or that generates legacy __init__.py files, keeps its dependencies in its own group. Describers only see providers, so this adds PyInfo.direct_implicit_pyc_files and PyExecutableInfo.venv_runfiles. Fixes bazel-contrib#3757
This was referenced Oct 12, 2026
Port to rules_runfiles_group's current API: the describers are held by _aspect_rule_hints, and the runtime group is merged in from the Python toolchain, described by py_runtime_pair. This drops the singleton python_runtime_runfiles target. Also fix two issues found testing against a real image: * A Python target in srcs (whl_library's :pkg wraps its :srcs) describes its own files, so the wrapper no longer claims them too. * With venvs_site_packages=yes, the venv's links to a wheel's files (shared libraries) go into that wheel's group instead of the binary's, so packagers keep them next to the files they point to.
…kspaces Revert once rules_runfiles_group is released.
FrankPortman
marked this pull request as ready for review
October 19, 2026 13:43
FrankPortman
requested review from
aignas,
dougthor42 and
rickeylev
as code owners
October 19, 2026 13:43
Picks up the analysis test comparing symlinks by path and target.
rules_runfiles_group's lib.bzl loads its packager code, which needs a recent bazel_features that WORKSPACE users don't have. Its new describe.bzl doesn't, so loading the Python rules works in WORKSPACE again without extra setup. The analysis tests still go through the packager, so the dev WORKSPACE gets bazel_features 1.51.0, and the tests are skipped on Bazel versions whose aspects can't walk toolchains.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Gives
py_library,py_binary/py_testandpy_runtime_pairrunfiles group describers for rules_runfiles_group, so packagers like rules_img'simage_from_binarycan split a Python binary into layers instead of shipping one big one.A packager walks the binary with its own aspect and asks each target what it adds, so nothing runs unless you package. No flags. The groups:
rules_python#runtime: interpreter and stdlib, merged in from the Python toolchain. Every binary on that toolchain shares it.rules_python#pypi/<name>: one per wheel. Withvenvs_site_packages=yes, the venv's links to a wheel's shared libraries go in that wheel's group too, so they stay next to the files they point at.py_library, and one per rule target indata.A binary whose
pyc_collectiondiffers from the configuration's, or that generates legacy__init__.pyfiles, keeps its deps in its own group, since their groups wouldn't match its runfiles.Notes:
PyInfo.direct_implicit_pyc_filesandPyExecutableInfo.venv_runfiles, since describers only see providers.python/private/BUILD.bazelloads rules_runfiles_group, so there's no autoload cycle on Bazel 8.Before merging:
DO NOT MERGEcommit points the nested workspaces at the dev registry and gets reverted then.Tested with
runfiles_group_analysis_test, which checks the groups add up to exactlydefault_runfileswith no overlap, across a bunch of binary shapes, and end to end with rules_img.Supersedes #3962. Written with LLM help (Claude); I've been through all of it and can own it in review.
Fixes #3757