Skip to content

Conversation

@rdesgroppes
Copy link
Contributor

@rdesgroppes rdesgroppes commented Feb 9, 2026

With any Python version on Windows, RUNFILES_* environment variables still point to an intermediate stage path instead of the module path, causing CurrentRepository() to raise a ValueError since rules_python v1.8.0:

ValueError: C:\Users\bot\AppData\Local\Temp\Bazel.runfiles_gh34ij5_\runfiles\+_repo_rules+cpython\my_script.py does not lie under the runfiles root C:/cache/ab1cdef2/execroot/_main/bazel-out/x64_windows-fastbuild/bin/external/+_repo_rules+cpython/install.exe.runfiles

This was not the case with rules_python v1.7.0. The issue stems from #3086 which, by eliminating a wrong assumption, also brought a stricter behavior.

Since #3086 came up with a corresponding workaround in //tests/runtime_env_toolchain:toolchain_runs_test, the proposed fix simply consists in moving it to CurrentRepository(), thus adding another case to the workaround introduced by #1634 for Python < 3.11. It therefore leads to assuming the main module path on Windows as well.

Removing the workaround from CurrentRepository() would make the test fail as follows:

==================== Test output for //tests/runtime_env_toolchain:toolchain_runs_test:
E
======================================================================
ERROR: test_ran (__main__.RunTest.test_ran)
----------------------------------------------------------------------
Traceback (most recent call last):
[...]
ValueError: C:\Users\user\AppData\Local\Temp\Bazel.runfiles_1f08smy6\runfiles\_main\tests\runtime_env_toolchain\toolchain_runs_test.py does not lie under the runfiles root c:\users\user\_bazel_user\cxxeswjo\execroot\_main\bazel-out\x64_windows-fastbuild-st-c530e4918e48\bin\tests\runtime_env_toolchain\toolchain_runs_test.exe.runfiles

Fixes #3579.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @rdesgroppes, I'm Gemini Code Assist1! 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 resolves a ValueError that occurs on Windows when using CurrentRepository() due to incorrect RUNFILES_* environment variable resolution. It introduces a workaround to correctly identify the main repository on Windows and adjusts a test case to reflect the fix.

Highlights

  • Windows Runfiles Path Resolution: Addresses an issue where RUNFILES_* environment variables on Windows point to an intermediate stage path, causing CurrentRepository() to raise a ValueError.
  • Workaround Implementation: Implements a workaround by assuming the main repository on Windows, similar to the existing workaround for Python versions < 3.11.
  • Test Adjustment: Removes a workaround from tests/runtime_env_toolchain/toolchain_runs_test.py as it is no longer needed with the fix in CurrentRepository().

🧠 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
    • Added a note indicating that a fix was made to CurrentRepository() to prevent a ValueError from being raised on Windows.
  • python/runfiles/runfiles.py
    • Modified CurrentRepository() to include a workaround for Windows, assuming the main repository when RUNFILES_* points to an intermediate stage path.
  • tests/runtime_env_toolchain/toolchain_runs_test.py
    • Removed a workaround that was previously in place to handle the incorrect runfiles path on Windows, as the issue is now resolved in CurrentRepository().
Activity
  • The PR addresses an issue introduced by a previous change (fix(runfiles): correct Python runfiles path assumption #3086) that resulted in stricter behavior regarding runfiles path validation.
  • The fix is based on a workaround previously implemented in the test suite.
  • The PR description includes a detailed explanation of the problem and the proposed solution, along with the error message observed without the fix.
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.

@rdesgroppes rdesgroppes force-pushed the fix-runfiles-on-windows branch from f6d5265 to 06bf932 Compare February 9, 2026 11:16
Copy link
Contributor

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

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 addresses a ValueError in CurrentRepository() on Windows by extending an existing workaround. The change correctly identifies the platform and assumes the main repository, which resolves the issue caused by incorrect runfiles environment variables. The code modification in python/runfiles/runfiles.py is clear and well-commented. As a positive side effect, the test in tests/runtime_env_toolchain/toolchain_runs_test.py is simplified by removing its own platform-specific workaround, which is now handled by the core fix. The changelog has also been updated appropriately. Overall, this is a solid fix.

With any Python version on Windows, `RUNFILES_*` environment variables
still point to an intermediate stage path instead of the module path,
causing `CurrentRepository()` to raise a `ValueError` since
`rules_python` v1.8.0:
```
ValueError: C:\Users\bot\AppData\Local\Temp\Bazel.runfiles_gh34ij5_\runfiles\+_repo_rules+cpython\my_script.py does not lie under the runfiles root C:/cache/ab1cdef2/execroot/_main/bazel-out/x64_windows-fastbuild/bin/external/+_repo_rules+cpython/install.exe.runfiles
```

This was not the case with `rules_python` v1.7.0. The issue stems from
bazel-contrib#3086 which, by eliminating a wrong assumption, also brought a stricter
behavior.

Since bazel-contrib#3086 came up with a corresponding workaround in
`//tests/runtime_env_toolchain:toolchain_runs_test`, the proposed fix
simply consists in moving it to `CurrentRepository()`, thus adding
another case to the workaround introduced by bazel-contrib#1634 for Python < 3.11.
It therefore leads to assuming the main module path on Windows as well.

Removing the workaround from `CurrentRepository()` would make the test
fail as follows:
```
==================== Test output for //tests/runtime_env_toolchain:toolchain_runs_test:
E
======================================================================
ERROR: test_ran (__main__.RunTest.test_ran)
----------------------------------------------------------------------
Traceback (most recent call last):
[...]
ValueError: C:\Users\user\AppData\Local\Temp\Bazel.runfiles_1f08smy6\runfiles\_main\tests\runtime_env_toolchain\toolchain_runs_test.py does not lie under the runfiles root c:\users\user\_bazel_user\cxxeswjo\execroot\_main\bazel-out\x64_windows-fastbuild-st-c530e4918e48\bin\tests\runtime_env_toolchain\toolchain_runs_test.exe.runfiles
```
@rdesgroppes rdesgroppes force-pushed the fix-runfiles-on-windows branch from ffa350a to 6b54911 Compare February 9, 2026 12:37
Copy link
Collaborator

@aignas aignas left a comment

Choose a reason for hiding this comment

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

Thank you, I think for the time being this might be good enough.

@aignas aignas added this pull request to the merge queue Feb 11, 2026
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Feb 11, 2026
@aignas aignas added this pull request to the merge queue Feb 11, 2026
Merged via the queue into bazel-contrib:main with commit f78add7 Feb 11, 2026
4 checks passed
@rdesgroppes rdesgroppes deleted the fix-runfiles-on-windows branch February 11, 2026 18:54
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.

Runfiles.CurrentRepository() raises ValueError on Windows

2 participants