Closed keith closed 1 month ago
+1 we'd love this primarily to fix #577
@fweikert ptal
One downside with this is that scripts that recursively call into bazel
might break now. They would work before because the tools directory is added to PATH
. If this allowed specifying the parent directory of the wrapper, but the wrapper had to be called bazel
, then that use case would continue to work.
yea i guess that's up to the user to manage if they rely on that. we could alternatively just allow a different directory vs different file name, since I imagine that's the more common thing that's important to override.
I'd be happy with different directory if it helps with the issue Brentley mentioned
It wouldn't entirely be in control of the user though, because the scripts I'm talking about are run targets, like rules_xcodeproj's project generation.
So I would prefer to limit it to the directory if possible.
updated
Thank you!
thanks!
In some projects the tools/bazel path isn't practical. This allows users to override this path with the BAZELISK_WRAPPER_DIRECTORY env var / .bazeliskrc config option. This allows overriding the root directory that the
bazel
wrapper executable should be found in. This was chosen over the file itself in order to continue supporting recursivebazel
invocations.