fix(toolchain): Also set Make variables for local toolchains

[jwnimmer-tri]

Related to the discussion in #3575, the BCR rules for @glib recently added a requirement that the Make variable $(PYTHON3) must always be defined by the current Python toolchain.

Here's a sample diff from that pull request bazelbuild/bazel-central-registry#7467 (see also full diff):

--- modules/glib/2.82.2.bcr.7/overlay/gio/BUILD.bazel	2026-02-13 11:42:20.203576551 +0000
+++ modules/glib/2.82.2.bcr.8/overlay/gio/BUILD.bazel	2026-02-13 11:42:20.205992896 +0000
@@ -1,5 +1,4 @@
 load("@bazel_skylib//rules:expand_template.bzl", "expand_template")
-load("@bazel_skylib//rules:run_binary.bzl", "run_binary")
 load("@rules_cc//cc:cc_library.bzl", "cc_library")
 load("//gobject:gobject.bzl", "mkenums")
 
@@ -23,7 +22,7 @@
             "%s.c" % target,
             "%s.h" % target,
         ],
-        cmd = ("$(location //gio/gdbus-2.0/codegen:gdbus_codegen) --interface-prefix {prefix} " +
+        cmd = ("$(PYTHON3) $(location //gio/gdbus-2.0/codegen:gdbus_codegen) --interface-prefix {prefix} " +
                "--output-directory $$(dirname $(location {target}.c)) " +
                "--generate-c-code {target} --c-namespace {namespace} {srcs}").format(
             srcs = " ".join(["$(location %s)" % s for s in srcs]),
@@ -32,6 +31,7 @@
             target = target,
         ),
         tools = ["//gio/gdbus-2.0/codegen:gdbus_codegen"],
+        toolchains = ["@rules_python//python:current_py_toolchain"],
     )
     for prefix, target, namespace, srcs in [
         [

However, if the user is using a "platform runtime" (local interpreter) instead of an "in-build interpreter" (hermetic), then the Make variable was not set, resulting in a @glib build error:

[1:34:52 AM]  ERROR: .../external/glib+/glib/BUILD.bazel:187:8: in cmd attribute of genrule rule @@glib+//glib:glib-visibility_h: $(PYTHON3) not defined

This change fixes that problem by setting both Make variables to the absolute path of the platform runtime.

---

Does this change seem like its on the right track?

I was less sure about setting $(PYTHON3_ROOTPATH) as well. I can remove that part if it seems suspicious.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical build issue within Bazel projects, specifically affecting rules that rely on Python toolchains. It ensures that Make variables like $(PYTHON3) and $(PYTHON3_ROOTPATH) are consistently defined, even when using local Python interpreters. This fix prevents build failures that occur when these variables are expected but not provided by the toolchain, thereby improving the robustness and compatibility of Bazel builds with external dependencies like @glib.

Highlights

• Python Toolchain Make Variables: Ensured that $(PYTHON3) and $(PYTHON3_ROOTPATH) (and similarly for Python 2) Make variables are correctly set when using local Python interpreters (platform runtimes) in Bazel toolchains. This resolves build errors, particularly for @glib rules, which now require these variables to be defined.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• CHANGELOG.md
  • (toolchain) Also set Make variables for local toolchains.
• python/current_py_toolchain.bzl
  • Added conditional logic to set PYTHON3/PYTHON2 and PYTHON3_ROOTPATH/PYTHON2_ROOTPATH Make variables when interpreter_path is available for platform runtimes.

Activity

• Initiated to address a discussion in run_binary() a py_binary() fails on a pure system (NixOS) #3575 regarding new requirements for Python Make variables in BCR rules.
• The author requested feedback on the approach, specifically questioning the inclusion of $(PYTHON3_ROOTPATH).

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request extends the logic for setting $(PYTHON...) Make variables to also cover local toolchains (platform runtimes). For platform runtimes, which use an absolute interpreter_path, both the PYTHON and PYTHON_ROOTPATH variables are set to this path. This ensures the variables are always defined. My review includes minor suggestions to improve code clarity by reducing redundancy.

[gemini-code-assist]

To improve readability and avoid redundant attribute access, you can store toolchain.py3_runtime.interpreter_path in a local variable.

Suggested change

	vars["PYTHON3"] = toolchain.py3_runtime.interpreter_path
	vars["PYTHON3_ROOTPATH"] = toolchain.py3_runtime.interpreter_path
	path = toolchain.py3_runtime.interpreter_path
	vars["PYTHON3"] = path
	vars["PYTHON3_ROOTPATH"] = path

[gemini-code-assist]

Similarly here, you can use a local variable to improve readability and avoid accessing the same attribute twice.

Suggested change

	vars["PYTHON2"] = toolchain.py2_runtime.interpreter_path
	vars["PYTHON2_ROOTPATH"] = toolchain.py2_runtime.interpreter_path
	path = toolchain.py2_runtime.interpreter_path
	vars["PYTHON2"] = path
	vars["PYTHON2_ROOTPATH"] = path