Explicitly provide Python toolchain, provide `python` in build container
This fixes being able to run py_binary targets within the build
container.
Each py_binary creates a stub that always has the #!/usr/bin/env python
shebang, and as such we need to have `python` available in the build
container. The stub then dispatches into the right Python interpreter,
which we now configure explicitely via rules_python's py_runtime_pair.
Test Plan: nothing breaks, future uses of py_binary (eg D389) will make actual use of this
X-Origin-Diff: phab/D390
GitOrigin-RevId: 78b6c51f09c720a46fbe2e6cbadb2a97d1161f7b
diff --git a/BUILD b/BUILD
index 99080be..29fce8d 100644
--- a/BUILD
+++ b/BUILD
@@ -57,3 +57,31 @@
"@org_golang_x_tools//go/analysis/passes/unusedresult:go_tool_library",
],
)
+
+load("@rules_python//python:defs.bzl", "py_runtime_pair")
+
+# Python toolchains - just use the host python for now.
+# TODO(T649): move to external (nix?) interpreters.
+py_runtime(
+ name = "host_python3",
+ interpreter_path = "/usr/bin/python3",
+ python_version = "PY3",
+)
+
+py_runtime(
+ name = "host_python2",
+ interpreter_path = "/usr/bin/python2",
+ python_version = "PY2",
+)
+
+py_runtime_pair(
+ name = "host_python_pair",
+ py2_runtime = ":host_python2",
+ py3_runtime = ":host_python3",
+)
+
+toolchain(
+ name = "host_python",
+ toolchain = ":host_python_pair",
+ toolchain_type = "@rules_python//python:toolchain_type",
+)