python stub_template.txt shouldn't assume /usr/bin/python always exists

[mzhaom]

Can it simply use %python_binary%?

For example, in a docker container we run, only python3 is available.

[kchodorow]

We should probably access python through an external dependency.

[xiongchiamiov]

This also implies that no matter what version of Python you specify in the py_* rules, you'll always end up using whatever /usr/bin/python is. I've resorted to doing things like ln -sn /usr/bin/python3 /usr/bin/python, but that's obviously dangerous and will mess up a bunch of things on a system if you're not careful.

[davidzchen]

There are also the --python2_path and --python3_path flags that determine which Python binary is set for %python_binary% and then resolved in the Python launcher, but unfortunately, /usr/bin/python is always used for running the launcher itself due to the hard-coded shebang.

[abergmeier-dsfishlabs]

Can we for the time being perhaps at least change the behavior, so if you have:

--force_python=PY3

or

--host_force_python=PY3

that it then uses /usr/bin/python3.
I do not know whether (the proper) /usr/bin/env python3 can work with Sandboxing enabled.

[jin]

re-assigning to the Python rules category. fyi @brandjon

[brandjon]

I believe this issue is referring to the shebang line at the top of the stub script. At the time this bug was filed, the shebang was #!/usr/bin/python, but it was changed to be #!/usr/bin/env python in 679e911.

There's still the problem that the interpreter running this wrapper is not necessarily the same one as %python_binary%. We can use this issue to track that.

[brandjon]

See #7947 for some discussion about using an arbitrary system interpreter for the stub logic versus using the exact interpreter specified by the target. The gist of it is:

1. The stub logic should be runnable with any reasonable interpreter, so it shouldn't matter which one gets used.
2. The stub can't necessarily use an interpreter from the zipped runfiles (as opposed to a system interpreter), because the stub is the thing responsible for extracting these runfiles. On Windows we do this anyway by pointing at the interpreter in the source tree or output tree instead of runfiles, but this is brittle.
3. We'd like to move the stub logic into a native executable that can do extraction (Don't require a system-installed Python interpreter for bootstrapping #8446). Then we don't need a separate interpreter to run stub logic at all.
4. In the meantime, I'd like to avoid adding separate features to customize the shebang or the Windows path to python.exe.

I'm going to close this bug. The resolution is that we currently require #!/usr/bin/env python to be valid on the target system, and #8446 tracks changing that.