feat: provide access to arbitrary interpreters #2507
Conversation
Run a specific interpreter: * `bazel run @rules_python//tools/run --@rules_python//python/config_settings:python_version=3.12` Run interpreter from a binary: * `bazel run @rules_python//tools/run --@rules_python//tools/run:bin=//my:binary`
$ bazel run //python/bin:repl
$ bazel run //python/bin:repl --//python/bin:repl_dep=//python/runfiles
| `@rules_python//python/bin:interpreter_src` target. | ||
|
|
||
| ``` | ||
| $ bazel run @rules_python//python/bin:interpreter --@rules_python//python/bin:interpreter_src=//path/to:bin |
There was a problem hiding this comment.
Need to find an "aha!" example for this.
There was a problem hiding this comment.
What about using the publishing twine binary? Something that exists within rules_python could do the trick.
There was a problem hiding this comment.
True, but I am looking for something that would produce different results from the default. AFAICT if I leave out --@rules_python//python/bin:interpreter_src=//path/to:bin then it'll default to the default Python toolchain. Since the twine would also use the default Python toolchain, it wouldn't really change the outcome.
@rickeylev , could you provide insight here? What use case are you covering with pulling the toolchain from a py_binary. I suspect I'm missing something simple here.
There was a problem hiding this comment.
The case I had in mind is a versioned py_binary. In such a case, the binary may have a different version from the top-level config.
There was a problem hiding this comment.
dev_pip//sphinx is available for 3.11 and 3.13.0, we could use that.
| ## Accessing the underlying interpreter | ||
|
|
||
| To access the interpreter that bazel manages, you can use the | ||
| `@rules_python//python/bin:interpreter` target. This is a binary target with |
There was a problem hiding this comment.
Nit: why not just python?
| `@rules_python//python/bin:interpreter` target. This is a binary target with | |
| `@rules_python//python/bin:python` target. This is a binary target with |
| @@ -0,0 +1,40 @@ | |||
| load("@bazel_skylib//lib:paths.bzl", "paths") | |||
There was a problem hiding this comment.
Please move the implementation to //python/private/interpreter.bzl and re-export here
| `@rules_python//python/bin:interpreter_src` target. | ||
|
|
||
| ``` | ||
| $ bazel run @rules_python//python/bin:interpreter --@rules_python//python/bin:interpreter_src=//path/to:bin |
There was a problem hiding this comment.
What about using the publishing twine binary? Something that exists within rules_python could do the trick.
| self._run_module_test("3.11") | ||
|
|
||
| def test_run_module_3_12(self): | ||
| self._run_module_test("3.12") |
There was a problem hiding this comment.
It would be great to add a test that imports:
- The code that is in the
//python/bin:interpreter_src - The code that is in the transitive deps of the
//python/bin:interpreter_src. Maybe depending ontwinecould be an option in the tests and then we could attempt importing one of its deps?
There are some use cases that folks want to cover here. They are
discussed in this Slack thread. The high-level summary is:
to minimize environmental issues.
so that they can use the correct interpreter.
This patch adds to @rickeylev's work from #2359 by adding docs
and a few integration tests.