refactor: use simplified rules_py providers#1231
Draft
jbedard wants to merge 4 commits into
Draft
Conversation
✨ Aspect Workflows Tasks📅 Fri Jul 10 19:21:52 UTC 2026 ✅ 36 successful tasks
⏱ Last updated Fri Jul 10 20:10:31 UTC 2026 · 📊 GitHub API quota 1,339/15,000 (9% used, resets in 2s) |
py_binary startup benchmark
sys.path quality
✅ No regression detected (PR is +1.7% vs HEAD main) |
jbedard
force-pushed
the
indi-provider
branch
3 times, most recently
from
6e42120 to
8a3b275
Compare
py_binary startup benchmark
sys.path quality
Bazel analysis benchmark
Auxiliary metrics
|
jbedard
changed the title
gregmagolan
approved these changes
Jul 9, 2026
Contributor
|
Drive-by feedback from moving a codebase fully onto With the direct rules_py's own e2e selects the version the same way ( |
tamird
reviewed
Jul 15, 2026
tamird
left a comment
tamird
left a comment
Contributor
There was a problem hiding this comment.
One downstream seam: this centralizes mixed-provider handling in private py_info_interop.bzl, but custom rules that inspect mixed rules_py/rules_python deps while emitting rules_py's PyInfo still need the same boundary. We have a concrete typing-source aggregator that would otherwise have to keep a direct rules_python load or reimplement this private helper. Could has_py_info/get_py_info, and perhaps RulesPythonPyInfo for attr constraints, be re-exported from //py:defs.bzl before this lands?
jbedard
added a commit
that referenced
this pull request
Jul 16, 2026
…s_python's Generated interpreter repos now instantiate a rules_py py_runtime_toolchain (py/private/interpreter/runtime.bzl, with a rules_py PyRuntimeInfo) instead of rules_python's py_runtime + py_runtime_pair + py_exec_tools_toolchain. One :runtime target per repo backs both toolchain registrations. Toolchain types are unchanged (@bazel_tools python type; rules_python's exec_tools type, with its exec_tools.exec_runtime/precompiler payload shape preserved), so rules_python-provisioned interpreters still satisfy whl_install/site-merge and rules_py still consumes user-registered rules_python py_runtime toolchains. This shrinks each interpreter repo's rules_python loads from 31 .bzl files to the 12 of the deliberately kept py_cc_toolchain chain, insulating provisioned toolchains from rules_python implementation churn, and leaves the runtime layer pinning no rules_python minimum version. New coverage: e2e/rules-python-interop (isolated module) pins that a module mixing both rulesets shares one rules_python-provisioned interpreter, including a $(PYTHON3) location diff_test; e2e/cases/rules-python-consumers pins that rules_python's own toolchain consumers (current_py_toolchain, exec-tools readers) work against rules_py-backed toolchains. Narrow breaks: - Generated interpreter repo targets are renamed: @python_X//:py3_runtime, :runtime_pair, and :exec_tools_toolchain are now a single @python_X//:runtime. Only direct label references need updating; toolchain resolution is unaffected. - rules_py-provisioned runtimes carry rules_py's PyRuntimeInfo, not rules_python's. Provider-indexed access (target[PyRuntimeInfo] with rules_python's symbol) on these targets or resolved toolchains breaks; duck-typed field access keeps working. As a consequence, rules_python's py_binary/py_test cannot execute on rules_py-provisioned toolchains (they read provider fields rules_py does not carry) — the same one-way interop direction #1231 establishes for PyInfo. - The exec-tools toolchain rules_py registers provides precompiler = None; enabling rules_python precompiling while @python_interpreters toolchains are registered first is unsupported.
jbedard
added a commit
that referenced
this pull request
Jul 16, 2026
…s_python's Generated interpreter repos now instantiate a rules_py py_runtime_toolchain (py/private/interpreter/runtime.bzl, with a rules_py PyRuntimeInfo) instead of rules_python's py_runtime + py_runtime_pair + py_exec_tools_toolchain. One :runtime target per repo backs both toolchain registrations. Toolchain types are unchanged (@bazel_tools python type; rules_python's exec_tools type, with its exec_tools.exec_runtime/precompiler payload shape preserved), so rules_python-provisioned interpreters still satisfy whl_install/site-merge and rules_py still consumes user-registered rules_python py_runtime toolchains. This shrinks each interpreter repo's rules_python loads from 31 .bzl files to the 12 of the deliberately kept py_cc_toolchain chain, insulating provisioned toolchains from rules_python implementation churn, and leaves the runtime layer pinning no rules_python minimum version. New coverage: e2e/rules-python-interop (isolated module) pins that a module mixing both rulesets shares one rules_python-provisioned interpreter, including a $(PYTHON3) location diff_test; e2e/cases/rules-python-consumers pins that rules_python's own toolchain consumers (current_py_toolchain, exec-tools readers) work against rules_py-backed toolchains. Narrow breaks: - Generated interpreter repo targets are renamed: @python_X//:py3_runtime, :runtime_pair, and :exec_tools_toolchain are now a single @python_X//:runtime. Only direct label references need updating; toolchain resolution is unaffected. - rules_py-provisioned runtimes carry rules_py's PyRuntimeInfo, not rules_python's. Provider-indexed access (target[PyRuntimeInfo] with rules_python's symbol) on these targets or resolved toolchains breaks; duck-typed field access keeps working. As a consequence, rules_python's py_binary/py_test cannot execute on rules_py-provisioned toolchains (they read provider fields rules_py does not carry) — the same one-way interop direction #1231 establishes for PyInfo. - The exec-tools toolchain rules_py registers provides precompiler = None; enabling rules_python precompiling while @python_interpreters toolchains are registered first is unsupported.
jbedard
added a commit
that referenced
this pull request
Jul 16, 2026
…s_python's Generated interpreter repos now instantiate a rules_py py_runtime_toolchain (py/private/interpreter/runtime.bzl, with a rules_py PyRuntimeInfo) instead of rules_python's py_runtime + py_runtime_pair + py_exec_tools_toolchain. One :runtime target per repo backs both toolchain registrations. Toolchain types are unchanged (@bazel_tools python type; rules_python's exec_tools type, with its exec_tools.exec_runtime/precompiler payload shape preserved), so rules_python-provisioned interpreters still satisfy whl_install/site-merge and rules_py still consumes user-registered rules_python py_runtime toolchains. This shrinks each interpreter repo's rules_python loads from 31 .bzl files to the 12 of the deliberately kept py_cc_toolchain chain, insulating provisioned toolchains from rules_python implementation churn, and leaves the runtime layer pinning no rules_python minimum version. New coverage: e2e/rules-python-interop (isolated module) pins that a module mixing both rulesets shares one rules_python-provisioned interpreter, including a $(PYTHON3) location diff_test; e2e/cases/rules-python-consumers pins that rules_python's own toolchain consumers (current_py_toolchain, exec-tools readers) work against rules_py-backed toolchains. Narrow breaks: - Generated interpreter repo targets are renamed: @python_X//:py3_runtime, :runtime_pair, and :exec_tools_toolchain are now a single @python_X//:runtime. Only direct label references need updating; toolchain resolution is unaffected. - rules_py-provisioned runtimes carry rules_py's PyRuntimeInfo, not rules_python's. Provider-indexed access (target[PyRuntimeInfo] with rules_python's symbol) on these targets or resolved toolchains breaks; duck-typed field access keeps working. As a consequence, rules_python's py_binary/py_test cannot execute on rules_py-provisioned toolchains (they read provider fields rules_py does not carry) — the same one-way interop direction #1231 establishes for PyInfo. - The exec-tools toolchain rules_py registers provides precompiler = None; enabling rules_python precompiling while @python_interpreters toolchains are registered first is unsupported.
jbedard
added a commit
that referenced
this pull request
Jul 16, 2026
…s_python's Generated interpreter repos now instantiate a rules_py py_runtime_toolchain (py/private/interpreter/runtime.bzl, with a rules_py PyRuntimeInfo) instead of rules_python's py_runtime + py_runtime_pair + py_exec_tools_toolchain. One :runtime target per repo backs both toolchain registrations. Toolchain types are unchanged (@bazel_tools python type; rules_python's exec_tools type, with its exec_tools.exec_runtime/precompiler payload shape preserved), so rules_python-provisioned interpreters still satisfy whl_install/site-merge and rules_py still consumes user-registered rules_python py_runtime toolchains. This shrinks each interpreter repo's rules_python loads from 31 .bzl files to the 12 of the deliberately kept py_cc_toolchain chain, insulating provisioned toolchains from rules_python implementation churn, and leaves the runtime layer pinning no rules_python minimum version. New coverage: e2e/rules-python-interop (isolated module) pins that a module mixing both rulesets shares one rules_python-provisioned interpreter, including a $(PYTHON3) location diff_test; e2e/cases/rules-python-consumers pins that rules_python's own toolchain consumers (current_py_toolchain, exec-tools readers) work against rules_py-backed toolchains. Narrow breaks: - Generated interpreter repo targets are renamed: @python_X//:py3_runtime, :runtime_pair, and :exec_tools_toolchain are now a single @python_X//:runtime. Only direct label references need updating; toolchain resolution is unaffected. - rules_py-provisioned runtimes carry rules_py's PyRuntimeInfo, not rules_python's. Provider-indexed access (target[PyRuntimeInfo] with rules_python's symbol) on these targets or resolved toolchains breaks; duck-typed field access keeps working. As a consequence, rules_python's py_binary/py_test cannot execute on rules_py-provisioned toolchains (they read provider fields rules_py does not carry) — the same one-way interop direction #1231 establishes for PyInfo. - The exec-tools toolchain rules_py registers provides precompiler = None; enabling rules_python precompiling while @python_interpreters toolchains are registered first is unsupported.
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
4 participants
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.
Remove the direct usage of the
rules_pythonPyInfoand create our own provider. MergePyVirtualInfointoPyInfoChanges are visible to end-users: yes
Outputs of
aspect_rules_pymay no longer be consumed byrules_python. All public entries intoaspect_rules_pisuch asdepsof any field still support outputs ofrules_python(including outputs ofprotobufwhich outputsrules_pythonspecific providers).Test plan