bazelbuild
fix: support `runfiles.CurrentRepository` with non-hermetic `sys.path`
When using Python 3.10 or earlier, the first sys.path entry is the directory containing the script. This can result in modules being loaded from the source root rather than the runfiles root, which the runfiles library previously didn't support.
Fixes #1631
The CI should be happy again if you rebase. We had some issues when this PR was created, if I remember correctly.
re: just assume the file is in the main repo if its loaded from outside the runfiles
Yeah, that's probably fine. This is to support older Python versions that were already relying on non-hermetic behavior.
I think this problem would only happen for files that are in the same directory (or a subdirectory of) as the main .py file? I don't see how an import would be able to find such files otherwise. So I suppose the sys.modules["__main__"].__file__ could be used in lieu of the caller's file in this situation. A main entry point that is in another repo and is relying on sys.path[0] being main's directory is likely for an ad-hoc tool in the main repo, but seems unlikely for any sort of library code.
The problem indeed does only surface in edge-cases where:
- Bazel 7 is used, with or without bzlmod
- Python 3.9 or earlier is used
- Runfiles rlocation is called from a file which is in the same directory as the main.py file (or test entry point)
But still I think this looks like the best solution for now, so it would be great to get this integrated if possible. Gentle ping @rickeylev
