Document effect of --incompatible_strict_action_env on autodetecting the Python interpreter

[mboes]

Description of the problem

Assume the following:

py_binary(
    name = "cmd",
    srcs = ["cmd.py"],
)

Now let's say that some rule foo's implementation has as one its actions to execute the cmd.py. While bazel run //:cmd works, executing cmd.py as part of an action, surprisingly, does not always work. The reason is that the python_binary rule will create a stub based on python_stub_template.txt, but the first line of this stub grabs whatever python is on the PATH. If --experimental_strict_action_env is turned on, then this might not be the intended python. In fact it's not even guaranteed that a python exists.

Consider the following scenario: PATH=/bin:/usr/bin:/usr/local/bin and python installed in /usr/local/bin. The rule action in the implementation of foo will fail, because python is not in the PATH that --experimental_strict_action_env uses (hardcoded to /bin:/usr/bin).

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

$ hub clone tweag/rules_haskell
$ cd rules_haskell
$ nix-shell
$ bazel build --experimental_strict_action

What operating system are you running Bazel on?

NixOS

What's the output of bazel info release?

bazel v0.18

[brandjon]

See also #7026.

The stub script uses the interpreter specified by the py_runtime pointed to by --python_top. If there is no such py_runtime, it defaults to the value of --python_path, which itself defaults to the command string "python".

The long-term solution is for us to create a py_toolchain rule (effectively acting as py_runtime) and a repository rule to automatically define/register a suitable toolchain based on a path lookup at workspace evaluation time. That way, we won't care what the PATH is at action execution time.

In the meantime, you can specify --python_top in your build and point it to a py_runtime with an interpreter_path value appropriate for your system.

[brandjon]

Just an update on how this would work with toolchains (#7375): There'll be a default Python toolchain that autodetects the Python interpreter on the system at execution time based on PATH. So if the strict action environment restricts PATH such that no suitable interpreter can be found, it'll continue to fail in this way. The solution is then to not rely on the default Python toolchain, but rather register your own one that knows what the correct absolute path to the runtime is on the target platform.

Under that system, this behavior is WAI and it's just a matter of documenting the effect of --experimental_strict_action_env on the autodetecting toolchain.

[brandjon]

See #8536 for interference between the strict action env and the autodetecting toolchain.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please post @bazelbuild/triage in a comment here and we'll take a look. Thanks!