-
-
Notifications
You must be signed in to change notification settings - Fork 636
fix(bootstrap): handle when runfiles env vars don't point to current binary's runfiles #3192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
8d86ecb to
b7122ce
Compare
…into fix.bin.calls.bin
…into fix.bin.calls.bin
|
@rickeylev is there a plan to turn on |
|
Eventually, yes. IIRC, the main blocker is Bazel 8+ is required for rules_pkg to be able to process py_binary correctly. #2521 is the tracking issue |
|
@rickeylev do you think the default could vary based on the Bazel version? Or maybe https://github.com/bazel-contrib/bazelrc-preset.bzl should set it? |
|
We technically can set a different default and it may be a good idea, that said, I wonder if we should wait for the packaging rules to properly support symlinks before we do the flip. |
The stage1 bootstrap script had a bug in the find_runfiles_root
function where it would unconditionally use the RUNFILES_DIR et al
environment variables if they were set.
This failed in a particular nested context: an outer binary
calling an inner binary when the inner binary isn't a data
dependency of the outer binary (i.e. the outer doesn't contain
the inner in runfiles). This would cause the inner binary to
incorrectly resolve its runfiles, leading to failures. Such
a case can occur if a genrule calls the outer binary, which has
the inner binary passed as an arg.
This change adds a check to validate that the script's entry point
exists within the inherited RUNFILES_DIR before using it. If the
entry point is not found, it proceeds with other runfiles discovery
methods. This matches the system_python runfiles discovery logic.
Fixes #3187