Skip to content

bazel run of py_binary target uses client PATH #8425

@keith

Description

@keith

Description of the problem:

Currently when setting up a py_runtime, any script you have called for the interpreter isn't called with any PATH, and ends up defaulting to the shell's default PATH, which can lead to using the wrong binaries depending on your system's configuration.

This was discovered while debugging #8414

In our case we exec bazel with env -i PATH=/usr/bin:/bin and pass --action_env=PATH=/usr/bin:/bin because we don't want user configuration to leak into the build. Because of this issue, you can see the error message in the linked issue is:

Failure reason: Cannot locate 'python3' or 'python' on the target platform's PATH, which is:
/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.

Where this default path (on macOS) appears to be coming from bash's default path (where /bin/sh on macOS is actually just bash), which is defined as:

/* The default value of the PATH variable. */
#ifndef DEFAULT_PATH_VALUE
#define DEFAULT_PATH_VALUE \
  "/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:."
#endif

Not being called with a PATH is what causes #8414 (although because of this default PATH you can export PATH to fix the specific issues there).

This issue cascades to this script as well https://github.com/bazelbuild/bazel/blob/b7a961517f928e6539b62f73bcb5b1c311396559/src/main/java/com/google/devtools/build/lib/bazel/rules/python/python_stub_template.txt that asks for /usr/bin/env python, which has to be pulled from the default PATH, which could result in a homebrew installed python (on macOS) instead of the system one.

It also attempts to read the PATH environment variable directly

search_path = os.getenv('PATH', os.defpath).split(os.pathsep)
which would never work in this case.

I believe the interpreter set for py_runtime should inherit the --action_env=PATH value set, if it is, and otherwise bazel should be calling these with a default PATH, and not falling back on the shell to do this itself.

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

Make the auto detection wrapper script echo $PATH and exit 1 https://github.com/bazelbuild/bazel/blob/1193e696b08f0932e1430c87dcfb51fe6c18d7e9/tools/python/pywrapper_template.txt and try to build a python target

What operating system are you running Bazel on?

macOS

What's the output of bazel info release?

development version

If bazel info release returns "development version" or "(@Non-Git)", tell us how you built Bazel.

bazel build src:bazel

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

https://github.com/bazelbuild/bazel
1193e69
1193e69

Have you found anything relevant by searching the web?

Related to #8414

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2We'll consider working on this in future. (Assignee optional)duplicateteam-Rules-PythonNative rules for Pythontype: bug

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions