Add optional attr python_interpreter to run pip with python 3

[acumon]

While it's possible to select which interpreter to run python rules with, pip will always be run with python from the system path.

This is an alternative solution to PR #82 and PR #85. it doesn't add pip3_import(). instead it adds python_interpreter attribute to pip_import(). Rationale is that if people want to use python3 for pip without changing the system's default python, they are likely also want to use python3.6 or python3.7 without changing the system's default python3 (for me it points to python 3.5) Using this approach users can any version of python, including customized built python with the interpreter path specified.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[acumon]

I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

[acumon]

I signed it!

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[acumon]

I signed it!

[googlebot]

CLAs look good, thanks!

[acumon]

Hi @brandjon, As this PR supersedes #82, Could you review this PR instead and have it merged or leaves some comments?

[beneisner]

Has there been any progress on this? Very excited to see this change, will help our workflow out a lot.

[akashgangil]

Can someone please look into this?

[pickledgator]

+1 for this!

[khurshidatcadre]

+1

[llchan]

Should this relate to --python_top in some way? It seems that if I'm already specifying a py_runtime(...), the pip steps should use the same python, no?

[llchan]

Nevermind, seems like that is on its way out. The python toolchain stuff is very actively changing (see e.g. bazelbuild/bazel#7899), so it might be good to let the dust settle there before we make a move here.

[bshashank]

Bump.

The python toolchain stuff is very actively changing (see e.g. bazelbuild/bazel#7899), so it might be good to let the dust settle there before we make a move here.

I'm not sure it'll help. The rules here are used at the analysis phase - in the WORKSPACE file, and these rules only have access to the repository_ctx, and this object does not have access to toolchains.

So we the workaround of specifying the interpreter in every pip_import invocation seems like a good workaround.

[cristifalcas]

Hi. We also really need this. Any love for this PR?

[Ragora]

I had to create a custom version of this repo just for this capability for work. Would be great to see this pulled officially.

[brandjon]

Thanks for the PR Chen. I've prioritized this feature as #249 and rebased your commit in #252.

As @bshashank pointed out, this is pretty independent of Python toolchains because this happens at WORKSPACE evaluation time. I imagine most users will only ever need to set it to "python", "python2", or "python3", so it should be sufficient to add pip2_import / pip3_import wrappers around this feature. But in a pinch, if you had some weird system with a non-standard Python command, you could hack up your WORKSPACE to override the pip_import repo rules with equivalent versions that have a modified python_interpreter line.