refactor: replace the magic sentinel string in the runtime env toolchain with a powershell wrapper

[rickeylev]

This implements a Windows equivalent to the Mac/Linux wrapper script for the
runtime-env toolchain. This helps eliminate a legacy code path where a special
value in the toolchain (aptly named _magic_pyruntime_sentinel_do_not_use)
would trigger non-toolchain fallback behavior on Windows and look at the
--python_path Bazel builtin flag to figure out what Python to use.

This allows removal of the --python_path Bazel builtin flag.

[gemini-code-assist]

Summary of Changes

Hello @rickeylev, 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 refactors the Python runtime environment toolchain to standardize its behavior across operating systems, particularly for Windows. It introduces a new PowerShell wrapper script that acts as the interpreter for Windows, thereby eliminating a legacy mechanism that used a "magic sentinel" string to trigger non-toolchain fallback behavior. This change simplifies the toolchain logic, removes a special case for Windows, and paves the way for the removal of the --python_path Bazel builtin flag.

Highlights

• Windows Toolchain Wrapper: A new PowerShell script, runtime_env_toolchain_interpreter.ps1, has been introduced to provide a dedicated wrapper for the runtime-env toolchain on Windows, aligning its functionality with existing Mac/Linux wrappers.
• Elimination of Magic Sentinel: The legacy _magic_pyruntime_sentinel_do_not_use string, which previously triggered non-toolchain fallback behavior on Windows, has been replaced with a direct reference to the new PowerShell wrapper in runtime_env_toolchain.bzl.
• Removal of Legacy Behavior: This change removes a specific legacy code path on Windows that relied on the magic sentinel value and the --python_path Bazel builtin flag, simplifying the toolchain's logic and standardizing its behavior.

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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

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 issue 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 refactors the runtime environment toolchain on Windows by replacing a magic sentinel string with a proper PowerShell wrapper script. This is a great improvement that removes a legacy hack and paves the way for removing the --python_path Bazel flag. The changes in the Bazel files are correct and achieve the goal. I've added a few suggestions for the new PowerShell script to improve its readability and align it with common PowerShell idioms.

[rickeylev]

Hrm. From CI:

LAUNCHER ERROR: Cannot launch process: "C:/b/bk-windows-s1tx/bazel/rules-python-python/python/private/runtime_env_toolchain_interpreter.ps1" C:\b\w5puohgx\execroot\_main\bazel-out\x64_windows-fastbuild-ST-1b13a798666d\bin\tests\runtime_env_toolchain\bootstrap_script_test.exe.runfiles\_main\tests\runtime_env_toolchain\bootstrap_script_test.zip
Reason: (error: 193): %1 is not a valid Win32 application.

Searching indicates this means that CreateProcess() can't be used with non-.exe programs. A powershell script would have to be invoked as e.g. powershell foo.ps1.

This might require getting rid of that infernal windows launcher.

Though, maybe if powershell is set as the exe, and then the path to the interpreter is passed in...

[rickeylev]

notes to self

The launcher logic is basically:

python = GetKey("python_bin_path")
if python_file := GetKey("python_file_short_path"):
  exec $python $python_file $@
elif GetKey("use_zip_file") == "1":
  exec $python ${0/.exe/.zip/} $@
else
  exec $python ${0/.exe//} $@

However, the python_file_short_path logic is 8.0 and higher only: bazelbuild/bazel@ae818c4

So, we could write powershell.exe to python_bin_path. However, we would then also have to change the stage1 bootstrap to a powershell script.