I had the issue that the binary wrapper fails when it is a data dependency of some other program which is run under bazel run (it does work under bazel test!)
The issue is that during bazel run RUNFILES_DIR may not be set and the MANIFEST file may not exist at ../.. even if you did not cd somewhere else.
The correct thing to do for the wrapper in this case is to accept the interpreter short path and main short path as-is from the starlark side. We can just set PATH_PREFIX=./ for the same effect.
I added a test that is red without the binary_wrapper change and becomes green when the change is applied. The trick here is to use env -i to remove the test envs from the sh_test so it behaves more like a bazel run and not bazel test.
Note that I don't think the binary_wrapper should explicitly fail anyways. Rather it should just let things play out. Other things will fail in any case if paths are not set up correctly. And if things won't fail -- well then the wrapper shouldn't make them fail either :)
I had the issue that the binary wrapper fails when it is a data dependency of some other program which is run under
bazel run(it does work underbazel test!) The issue is that during bazel run RUNFILES_DIR may not be set and the MANIFEST file may not exist at ../.. even if you did not cd somewhere else. The correct thing to do for the wrapper in this case is to accept the interpreter short path and main short path as-is from the starlark side. We can just set PATH_PREFIX=./ for the same effect.I added a test that is red without the binary_wrapper change and becomes green when the change is applied. The trick here is to use
env -ito remove the test envs from the sh_test so it behaves more like a bazel run and not bazel test.Note that I don't think the binary_wrapper should explicitly fail anyways. Rather it should just let things play out. Other things will fail in any case if paths are not set up correctly. And if things won't fail -- well then the wrapper shouldn't make them fail either :)