feat(toolchains): let local toolchains point to a label #3304
Conversation
By letting a local toolchain point to a label, it allows Bazel repository rules to manage the download and creation of the Python runtime itself. This makes it easy to customize where a runtime is coming from.
Summary of ChangesHello @rickeylev, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the flexibility of local Python toolchains by introducing the ability to specify the Python interpreter using a Bazel label. Previously, toolchains were limited to resolving interpreters via direct file paths or program names on the system's PATH, which proved insufficient for scenarios where Bazel itself manages the Python runtime (e.g., through repository rules that download or build Python). The new Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable feature by allowing local_runtime_repo to reference a Python interpreter via a Bazel label (interpreter_target). This is particularly useful for scenarios where runtimes are managed by Bazel itself. The implementation is solid, with appropriate logic for mutual exclusivity and path resolution. The addition of comprehensive tests and documentation is also commendable. I've identified a critical syntax error in one of the test files that needs to be fixed, and a high-severity issue in a new repository rule that could lead to insecure downloads. Once these are addressed, this PR will be in great shape.
…into tests.use.pbs.for.local.toolchain
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_targetattribute tolocal_runtime_repo, which itlooks 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.