Specify 2.7 instead of 2 for python version

[keith]

This changes the python setup to prefer an executable named python2.7
over python2. This fixes an issue on macOS where it doesn't ship with
a python2 executable, but you can install one from homebrew, but
really you'd prefer to be using the system python2.7 binary. I assume
that this isn't a huge issue because bazel likely doesn't support
versions of python before 2.7.

Follow up to 3a4be3c

[keith]

cc @brandjon (we also discussed this in slack), this is meant to fix this issue #8536 (comment)

[keith]

Another option in our case is to stop passing --experimental_strict_action_env since we set PATH explicitly with --action_env=PATH and env -i PATH=... bazel

[keith]

Any thoughts on something like this @brandjon ?

[brandjon]

Hi Keith,

This change makes it so the autodetecting toolchain's PY2 runtime would 1) look for the command python2.7 (instead of python2) on PATH, and 2) fallback on python if that can't be found (same as before). This feels a bit ad hoc. Currently we don't have a notion of distinguishing between Python minor versions except in the toolchain; why should the default toolchain single out 2.7?

To get precise control over what interpreter is picked, I'd use an explicit Python toolchain instead of relying on the default autodetecting one.

[keith]

The core issue I'm trying to fix here is that python2 isn't provided by macOS, so we have to use python2.7 specifically. I figured singling out 2.7 was pretty safe since I assume support for <python 2.7 isn't really something we're worried about since folks likely aren't on older versions. We could totally switch to our own toolchain to work around this but this is a subtle bit of non-hermaticity described here #8536 (comment) that I think it would be nice to fix for everyone

[lzell]

Is there any harm in looking for the OS X system-installed python2.7 binary first, then falling back to python2 if not found?

[ulfjack]

Ping @brandjon

[aiuto]

ping @brandjon

[keith]

I assume at this point this won't matter for much longer because python 2 support will be removed?

[brandjon]

We're not removing support for building and running Python 2 code using Bazel. We've only removed the expectation that Bazel itself (and some language-specific tooling) will work with Python 2.

The issue with this PR is that it is a backwards-incompatible change that solves the problem in an ad hoc way, by changing the default for everyone, to accommodate a situation that is particular to a given environment and IMO better addressed by choosing an explicit toolchain.

(That said, there is some precedent for tweaking the Python interpreter location based on platform in #10432, although that case was for the stub script shebang, and would be eliminated by a future improvement to allow toolchains to specify the shebang string.)

[aiuto]

Given the last comments, I'm assuming this PR is dead on arrival.
I'll close in a week if I don't hear from anyone.

[keith]

FWIW this is still an issue. I haven't heard an alternative path to fixing this but we might want to. I assume with the current state of python2 at this point folks are feeling super motivated to support this though.