Skip to content

feat: expose interpreter files-to-run on PyRuntimeInfo#3795

Merged
rickeylev merged 2 commits into
bazel-contrib:mainfrom
jsun-splunk:jsun-files-to-run
Jun 17, 2026
Merged

feat: expose interpreter files-to-run on PyRuntimeInfo#3795
rickeylev merged 2 commits into
bazel-contrib:mainfrom
jsun-splunk:jsun-files-to-run

Conversation

@jsun-splunk

@jsun-splunk jsun-splunk commented May 22, 2026

Copy link
Copy Markdown
Contributor

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.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

@rickeylev, @aignas - any chance of a review?

Comment thread python/private/py_runtime_rule.bzl Outdated
Comment thread python/private/py_runtime_rule.bzl Outdated
jsun-splunk added a commit to jsun-splunk/rules_pycross that referenced this pull request Jun 10, 2026
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
@jsun-splunk jsun-splunk requested a review from matt-sm June 10, 2026 06:15
Comment thread python/private/py_runtime_rule.bzl Outdated
Comment thread python/private/py_runtime_info.bzl

@rickeylev rickeylev left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! It's bugged me that a FilesToRun-providing target could be fed into py_runtime, but it wasn't well preserved after passing through it.

Mostly LGTM. The interpreter_files_to_run isn't being passed into PyRuntimeInfo from py_runtime. Please fix (a test to verify that would be nice, too, but not going to block on that).

For my own edification, how might the code in https://github.com/bazel-contrib/rules_python/blob/main/python/private/common.bzl#L643 (_actions_run, the if PyInterpreterProgramInfo ... code path) be updated to use this? (that some internal helper code we have for running via an action) If I'm understanding right, something like this?

exec_runtime = ctx.toolchains[EXEC_TOOLS_TOOLCHAIN_TYPE].exec_tools.exec_runtime
...
ctx.actions.run(
  executable = [exec_runtime.interpreter_files_to_run],
  ...
)

Or it could be put into tools for a more complex case.

Comment thread python/private/py_runtime_rule.bzl Outdated
@jsun-splunk

Copy link
Copy Markdown
Contributor Author

Thanks for this! It's bugged me that a FilesToRun-providing target could be fed into py_runtime, but it wasn't well preserved after passing through it.

Mostly LGTM. The interpreter_files_to_run isn't being passed into PyRuntimeInfo from py_runtime. Please fix (a test to verify that would be nice, too, but not going to block on that).

For my own edification, how might the code in https://github.com/bazel-contrib/rules_python/blob/main/python/private/common.bzl#L643 (_actions_run, the if PyInterpreterProgramInfo ... code path) be updated to use this? (that some internal helper code we have for running via an action) If I'm understanding right, something like this?

exec_runtime = ctx.toolchains[EXEC_TOOLS_TOOLCHAIN_TYPE].exec_tools.exec_runtime
...
ctx.actions.run(
  executable = [exec_runtime.interpreter_files_to_run],
  ...
)

Or it could be put into tools for a more complex case.

You are correct, except you don't need to wrap files_to_run in a list. So it will be

ctx.actions.run(
  executable = exec_runtime.interpreter_files_to_run,
  ...
)

adding the same to tools will make the executable and its runfiles available in the action space too.

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.
@rickeylev rickeylev enabled auto-merge June 17, 2026 04:52
@rickeylev rickeylev added this pull request to the merge queue Jun 17, 2026
Merged via the queue into bazel-contrib:main with commit 102b501 Jun 17, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants