Hi, Ollie! Great to meet you. Just seeing this and your issue--sorry a little backed up over here. Thanks for being the kind of person who aims to leave things better than you found them!

I'm certainly open to this in spirit, but I'm pretty sure I recall the last person who raised this finding that the Bazel idiomatic way of doing this was to use some built-in magic Bazel functionality for wrapper scripts, rather than configure by tool. Maybe it was to put the wrapper in tools/bazel? Is that something you've already tried?

Cheers--and happy coding!
Chris

Thanks for getting back to me!
That would be the optimal way forward. However, it does not apply to our case since the wrapper downloads the specified Bazel-toolchain (and other dependencies) from a Nexus binary repository. We do not rely on a local installation of Bazel (so calling bazel in the repository is not even possible). It might be possible by using Bazelisk or some shell alias.

oh i didn't check for this and filed something similar #194

in our case we don't have a bazel in the $PATH since we're intentionally limiting the PATH to something that we're sure is hermetic. so we want to reroute this to a wrapper that manages the current install

IMO this PR is better than mine since you can set it on the rule

@cpsauer what is you stance on merging this? Missing anything or should we begin to patch our local installation?

Hey Ollie--stance is positive and want to support rather than making you maintain a patch. Just got backlogged. Sorry :/

Do want to make sure there's not a better way--e.g. you guys are pretty sure you don't want this as an environment variable, right? This seems like something you'd want inherited by all refresh_compile_command rules, even ones already defined, like :refresh_all, and this seems more like a per-setup kind of thing than a per-rule or per-repo.

I'd propose just using PATH to add your wrapper script, Ollie, but @keith, it sounds like that doesn't work for you? Anything more I should know there about the hermiticity concerns there? I presume you're passing --incompatible_strict_action_env, and that it doesn't work to put it on your path just for these calls, like PATH="<wherever_bazel_is>:$PATH" bazel run @hedron_compile_commands//:refresh_all

Edit: Ollie, might the bazel idiomatic way of doing this be to use bazelisk to get bazel and then tools/bazel to get the rest?

Yea for sure in our case it wouldn't be in the PATH. It's just a wrapper binary at the root of the repo that makes the UX better by not requiring users to have any bazel install ahead of time, or think about version issues.