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
docs/toolchains.md
Outdated
| `@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.
There was a problem hiding this comment.
I will look at those, thank you.
docs/toolchains.md
Outdated
| `@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 was a problem hiding this comment.
Unless I'm misunderstanding something, that's currently not possible with the current implementation. The current implementation is purely there to get the interpreter, nothing else.
I'd like to follow this PR up with another PR that enables the use of the REPL with a specific py_* target (and its dependencies) importable.
| @@ -120,6 +120,11 @@ rules_python_integration_test( | |||
| py_main = "custom_commands_test.py", | |||
| ) | |||
|
|
|||
| rules_python_integration_test( | |||
There was a problem hiding this comment.
Instead of a bazel-in-bazel integration test, use transitions to set the appropriate state. The BiB tests are slow and painful to run and debug. There is some code in //tests/support:sh_py_run_test.bzl that has most of this already you should be able to use with some modifications.
There was a problem hiding this comment.
I thought about that, but figured most use cases involve a bazel run //python/bin:python so I wanted to make sure that that's tested. But I can see the argument about it being annoying etc. Will change it.
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.