Allow python_register_toolchains.name to be the resolved interpreter repo

[UebelAndre]

PR Checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature (please, look at the "Scope of the project" section in the README.md file)
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

Currently documentation suggests that users write the following in their WORKSPACE file to produce a python toolchain

load("@rules_python//python:repositories.bzl", "python_register_toolchains")

python_register_toolchains(
    name = "python3_9",
    # We recommend using the same version your team is already standardized on.
    python_version = "3.9",
)

This then creates a "magic" repository called python3_9_resolved_interpreter, which is based on the name value. I call it magic because it's generally the next thing users want to use in their workspaces (needing to load dependencies via pip_repository rules) but will need to read docs to find the _resolved_interpreter name. I personally find it much more intuitive to allow anything that's called in a WORKSPACE and has a name parameter to actually create a repository matching that name. This makes things more discoverable and easier to maintain.

Issue Number: N/A

What is the new behavior?

This change introduces a second resolved_interpreter_os_alias rule which just uses the name attribute as it's name instead. This has the added benefit of allowing users to wrap the macro in maybe to avoid redundant calls to these repository rules.

Does this PR introduce a breaking change?

• Yes
• No

Other information

[f0rmiga]

I don't like this, but I'll let others chime in. Without the resolved_interpreter suffix, it implies that a toolchain is the host interpreter, which is not true.

cc @mattem @alexeagle @thundergolfer

[UebelAndre]

I don't like this, but I'll let others chime in. Without the resolved_interpreter suffix, it implies that a toolchain is the host interpreter, which is not true.

cc @mattem @alexeagle @thundergolfer

Thanks for the quick response!

I mostly don't like the feeling that the only repository rule I'll generally interact with is magically created for me. In most cases, name = "foo" produces a repository and I think this is the most appropriate.

I'm not married to this change though but do think it's less burden-of-knowledge, which I like.

[thundergolfer]

I do agree with @UebelAndre that this breaks Bazel user expectations about repository rules:

A custom repository rule can be used just like a native repository rule. It has a mandatory name attribute and every target present in its build files can be referred as @<name>//package:target where <name> is the value of the name attribute. - bazel.build/rules/repository_rules

Currently the rule doesn't produce a @<name> external repository, which is unusual.

[alexeagle]

This goes all the way back to the template
https://github.com/bazel-contrib/rules-template/blob/main/mylang/repositories.bzl#L70-L74
which I wrote after revamping the toolchains design in rules_nodejs. It has this issue as well.

I don't see a good reason why that macro doesn't include the given name in its expansion, like the macro style guide indicates. Naming the "default" repository as the thing most users want to use makes sense to me. In many cases users don't think about the nuances of host/target/exec platforms anyway. More sophisticated users who do care about that will likely be able to read documentation explaining that the default repository is the one that toolchain selection would pick for the host.

[mattem]

personally find it much more intuitive ...

Yeah, I generally agree with this sentiment, and the thing the user cares about is the "resolved" version, not strictly the toolchain (which is kinda abstracted anyway).

An alternative is to add further alias targets manually, eg //python:default to be the interpreter etc.
eg at one client we have multiple interpreter versions in a single graph, so //python:default, //python:py37 etc are all aliased to the interpreter bin, and can create a more intuitive bazel run statement.