feat: expose interpreter files-to-run on PyRuntimeInfo#3795
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces the interpreter_files_to_run field to PyRuntimeInfo, allowing action consumers to execute an in-build runtime interpreter along with its runfiles. The changes include updates to the py_runtime rule to populate this field when an executable target is provided, validation logic to ensure consistency between the interpreter and its runfiles provider, and comprehensive tests to verify the new functionality and error handling. I have no feedback to provide.
jsun-splunk
force-pushed
the
jsun-files-to-run
branch
from
cbf8104 to
94107d7
Compare
|
@rickeylev, @aignas - any chance of a review? |
jsun-splunk
force-pushed
the
jsun-files-to-run
branch
from
94107d7 to
88b3b8c
Compare
| # keep py_runtime's file-only behavior and not populate | ||
| # interpreter_files_to_run. Rule targets have OutputGroupInfo; direct | ||
| # file targets do not. | ||
| is_file_target = OutputGroupInfo not in interpreter |
There was a problem hiding this comment.
Could this key off interpreter_file.is_source instead of the OutputGroupInfo check? The case you're guarding against is really a source file — that's the only non-executable input with a files_to_run.executable — and is_source doesnt rely on which providers Bazel attaches to rule vs
file targets.
There was a problem hiding this comment.
you are correct, .is_source is the better choice.
| if _is_singleton_depset(interpreter_di.files): | ||
| interpreter_file = interpreter_di.files.to_list()[0] | ||
|
|
||
| if is_file_target and interpreter_file: |
There was a problem hiding this comment.
Is it worth noting somewhere that source-file interpreter now takes this path instead of the executable branch?
eg. py_runtime(interpreter = ...) pointing at a downloaded/extracted file @python_x86_64//:bin/python3 rather than a *_binary
This used to hit the executable branch and pick up the runfiles.merge/runtime_files expansion, and now skip it.
There was a problem hiding this comment.
You caught an unintended behavioural change. I've restructured the if statement so source-file interpreter goes through the old route that collects the runfiles too.
jsun-splunk
force-pushed
the
jsun-files-to-run
branch
from
88b3b8c to
9f93262
Compare
Add support for pycross_wheel_build to use PyRuntimeInfo.interpreter_files_to_run when selecting the Python executable for wheel build actions. This adds support for runtimes that expose a launcher or other executable wrapper instead of relying directly on interpreter.path. Carry the FilesToRunProvider through the pycross toolchain info as well, so configured pycross toolchains and the default Python toolchain path use the same runtime executable shape. This depends on the PyRuntimeInfo update that adds FilesToRunProvider support: bazel-contrib/rules_python#3795
Rules that execute a py_runtime interpreter in an action need the interpreter executable together with its runfiles metadata. The existing PyRuntimeInfo fields identify the interpreter file and runtime files, but do not preserve the target's FilesToRunProvider for executable interpreter targets. Add PyRuntimeInfo.interpreter_files_to_run for runtimes created from an executable interpreter target, and validate that direct provider construction keeps the FilesToRunProvider executable aligned with the interpreter field. Direct file interpreters and platform runtimes continue to leave this field unset, preserving existing py_runtime behavior. Document the new public provider field and add focused analysis-test coverage for executable, file-only, platform, and invalid constructor cases.
jsun-splunk
force-pushed
the
jsun-files-to-run
branch
from
9f93262 to
080e417
Compare
2 participants
Rules that execute a py_runtime interpreter in an action need the interpreter executable together with its runfiles metadata. The existing PyRuntimeInfo fields identify the interpreter file and runtime files, but do not preserve the target's FilesToRunProvider for executable interpreter targets.
Add PyRuntimeInfo.interpreter_files_to_run for runtimes created from an executable interpreter target, and validate that direct provider construction keeps the FilesToRunProvider executable aligned with the interpreter field. Direct file interpreters and platform runtimes continue to leave this field unset, preserving existing py_runtime behavior.
Document the new public provider field and add focused analysis-test coverage for executable, file-only, platform, and invalid constructor cases.
One example is rules_pycross wheel building with an in-build executable Python runtime. pycross needs to run the selected Python interpreter in an action, but PyRuntimeInfo previously exposed only the interpreter File and runtime files, not the interpreter target's FilesToRunProvider. For executable in-build runtimes, the FilesToRunProvider is the Bazel-native handle that carries both the executable and the runfiles metadata needed to stage it as an action tool. Exposing it lets pycross consume the runtime interpreter directly for wheel-build actions instead of reconstructing or approximating the interpreter's runtime closure from separate fields.