You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(toolchains): let local toolchains point to a label (#3304)
Currently, the local toolchain code requires using a path (or program
name) to find
the Python interpreter. This comes up short when using Bazel to
download an arbitrary runtime (or otherwise manage the creation of it,
e.g.
downloading Python and building it from source in a repo rule). In such
cases, the
file system location of the interpreter isn't known (it'll be in some
Bazel cache
directory).
To fix, add the `interpreter_target` attribute to `local_runtime_repo`,
which it
looks up the path for, then continues on as normal. As an example, the
test uses
a custom repository rule to download a particular version of Python
appropriate
to the OS.
"mac os x": "https://github.com/astral-sh/python-build-standalone/releases/download/20250918/cpython-3.13.7+20250918-x86_64-apple-darwin-install_only.tar.gz",
50
+
"windows server 2022": "https://github.com/astral-sh/python-build-standalone/releases/download/20250918/cpython-3.13.7+20250918-x86_64-pc-windows-msvc-install_only.tar.gz",
51
+
},
52
+
)
53
+
54
+
# This will use Python from the `pbs_runtime` repository.
55
+
# The pbs_runtime is just an example; the repo just needs to be a valid Python
"mac os x": "https://github.com/astral-sh/python-build-standalone/releases/download/20250918/cpython-3.13.7+20250918-x86_64-apple-darwin-install_only.tar.gz",
40
+
"windows server 2022": "https://github.com/astral-sh/python-build-standalone/releases/download/20250918/cpython-3.13.7+20250918-x86_64-pc-windows-msvc-install_only.tar.gz",
0 commit comments