python_stub_template.txt's use of env python ignores py_toolchain config

[justhecuke-zz]

ATTENTION! Please read and follow:

• if this is a question about how to build / test / query / deploy using Bazel, or a discussion starter, send it to bazel-discuss@googlegroups.com
• if this is a bug or feature request, fill the form below as best as you can.

Description of the problem / feature request:

On a machine without python where we want to setup a python toolchain that points to python2.7, it looks like this python_stub_template.txt does not respect the toolchain and instead hardcodes the use of env python when doing a bazel run //some:py_binary and eventually causes an error: /usr/bin/env: 'python': No such file or directory

I found python_stub_template.txt through looking through the output of bazel build //some:py_binary and searching for a comment that stood out to me as reasonable unique: "Return True if running on Windows"

Feature requests: what underlying problem are you trying to solve with this feature?

Replace this line with your answer.

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

I'm not able to verify that this is a minimal example or that it fully reproduces the issue because my development and test systems are different.

bazel run //some:py_binary

//BUILD.bazel

load("@rules_python//python:defs.bzl", "py_runtime", "py_runtime_pair")
py_runtime(
    name = "py2_runtime",
    interpreter_path = "/usr/bin/python2.7",
    python_version = "PY2",
)

py_runtime_pair(
    name = "py_runtime_pair",
    py2_runtime = ":py2_runtime",
    py3_runtime = None,
)

toolchain(
    name = "py_toolchain",
    toolchain = ":py_runtime_pair",
    toolchain_type = "@rules_python//python:toolchain_type",
)

//WORKSPACE

http_archive(
    name = "rules_python",
    sha256 = "aa96a691d3a8177f3215b14b0edc9641787abaaa30363a080165d06ab65e1161",
    url = "https://github.com/bazelbuild/rules_python/releases/download/0.0.1/rules_python-0.0.1.tar.gz",
)

load("@rules_python//python:repositories.bzl", "py_repositories")

py_repositories()

register_toolchains("//:py_toolchain")

//some/BUILD

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

//some/py_binary.py

print('Hello World!')

What operating system are you running Bazel on?

Ubuntu 18.04.3 LTS

What's the output of bazel info release?

release 1.0.0

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

N/A

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

git@github.com:lyft/instant-android.git
5ed105a471629bdbc4ce06be7e66908bd845ff4a
0dacf5733ef8d60c4f62a12d1127eece334092a2

Have you found anything relevant by searching the web?

Yes. There was a bug suggesting the use of --python_top and a py_runtime target. However, on v1.0.0 --python_top is deprecated and I had already been using the true solution which was to make a toolchain.

#7899
States to use toolchain_type = "@bazel_tools//tools/python:toolchain_type" rather than the @rules_python//python:toolchain_type that https://github.com/bazelbuild/bazel/blob/1.0.0/tools/python/toolchain.bzl#L104 suggests. I use rules_python because that seems to be the most-recent instruction.

Any other information, logs, or outputs that you want to share?

No.

[justhecuke-zz]

The easy workaround is to add a symlink ln /usr/bin/python2.7 /usr/bin/python so that env python can resolve to something. This, obviously, isn't useful for repos with a py2/3 mix.

[brandjon]

The interpreter is only used for the stub script, whose job is (among other things) to launch the interpreter specified by the toolchain on the payload code. Currently the stub cannot use the toolchain interpreter directly to run itself. Closing this as a dup of #8685 and #8446.

@justthecuke The stub script can run as either PY2 or PY3 so it's safe for both.

Essentially, the Python rules do require that a system Python interpreter be available, even if it's not the same one your toolchain uses to launch the underlying user Python program.