bazel-contrib / bazel-contrib/rules_python
Support incompatible_strict_action_env
- Dominant language
- Starlark
- Stars
- 688
- Forks
- 721
- Avg merge
- 14h 49m
- Merged PRs (30d)
- 81
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)
Contributor guide
Assessment
This issue has not been assessed yet.