Ignas Anikevicius

I think for now just skipping the `examples/bzlmod` would be cleanest, however, I realised that we are using this example in publishing the module to BCR, so the current situation...

# idea 1 - running the command `lldb -- python3 -m pytest path/to/tests` A few thoughts, since we need the `$(PYTHON3)` interpreter reference in most of the commands here and...

I guess you would have to change [this line](https://github.com/bazelbuild/rules_python/blob/main/python/private/stage1_bootstrap_template.sh#L128) to somehow inject `lldb` in order for this to work. The annoying thing is that for the python interpreter to work,...

I like the first approach more but would love to see if there are better options for the migration. It could suddenly be the case where gazelle might start failing,...

Wanted to create a separate issue for this but realized that this is already there. We could just create a `python.override` tag class for the majority of the things listed...

Ideally it would be great to start using the `MODULE.bazel` configuration as the source of truth rather than the `versions.bzl` file. Maybe we could have the `versions.bzl` `PLATFORMS` constant updated...

> Yes. I'll take it a step further: I like the idea of fetching a remote config of all available toolchains (i.e. all ~500 python-build-standalone runtimes). But, by default, we...

I tried implementing it with bigger granularity, but then the question is what gets passed as `whl` and `py_library` deps because those could be something like ``` deps = ["//foo:pkg"]...

#2347 has replaced this when it comes to better abstractions. Whereas the overriding of the targets is a separate question.

I'll try to add my two cents about how I understand what the ask is. I think we are conflating here quite a few problems. 1. Right now the pip.parse...