-
-
Notifications
You must be signed in to change notification settings - Fork 677
Description
As of Bazel 9, --incompatible_strict_action_env=true is the default.
Almost everything works with that set, the one exception is Windows in a particular case. That particular case appears to be when the python program is a data dep of another binary, e.g. an sh_binary with a py_binary in data. What happens is the Bazel launcher can't find the python interpreter in runfiles, so falls back to looking for python.exe on PATH. When strict action env is enabled, the outer PATH isn't inherited, so python.exe can't be found, and thus the launcher fails to execute.
A direct execution of a python program is ok, since the runfiles structure is present enough that the bazel launcher can find the interpreter.
Other than moving away from the Bazel launcher, I don't see a way to solve this. We've wanted to stop using the bazel launcher anyways, so this isn't a big deal, this case just add additional pressure to do so.
Fundamentally, when a binary is running within another binary's runfiles, the logic to find things is a bit more convoluted. We can use RunEnvironmentInfo so that tests auto-inherit PATH, but this only helps tests. binaries-in-binaries or binaries-run-by-actions wouldn't be affected.
There are two workarounds:
- Set
--incompatible_strict_action_env=false(restore non-strict env behavior, which includes PATH) - Set
--action_env=PATH(only inherit PATH for actions)