Labels passed to module extensions don't survive until BUILD time

[shs96c]

Description of the problem / feature request:

I am attempting to modularise apple_rules_lint. Users will register linters using a call similar to this in their MODULE.bazel:

bazel_dep(name = "apple_rules_lint", version = "1.0")

lint = use_extension("@apple_rules_lint//lint:extensions.bzl", "lint")

lint.register(
    linters = {
        "lint_example": ":default_config",
    }
)

Behind the scenes, this creates a new @apple_linters workspace that is only ever used by apple_rules_lint (which apple_rules_lint declares it uses). This generated workspace contains a build file similar to:

load("@apple_rules_lint//lint/private:package_lint_config.bzl", "package_lint_config")

package(default_visibility = ["//visibility:public"])

package_lint_config({"lint_example": "@//:default_config"})

exports_files(["defs.bzl"])

The repository rule used to create this workspace has expanded the :default_config to @//:default_config, which when not using bzlmod correctly refers to main workspace of the project.

When using bzlmod, the following error occurs:

INFO: Invocation ID: e824bad2-8380-47f5-8e18-9ce432597e1b
ERROR: /private/var/tmp/_bazel_shs/baa711eaf956438e603fe4894fbbe19d/external/apple_rules_lint.lint.apple_linters/BUILD.bazel:6:20: no such package '': Invalid package reference  crosses into repository @: did you mean to use  instead? and referenced by '@apple_rules_lint.lint.apple_linters//:package_lint_config_lint_example'
ERROR: Analysis of target '//project:will_fail-test' failed; build aborted: 

Feature requests: what underlying problem are you trying to solve with this feature?

I want to automatically add linters to a project, and there's no way of knowing beforehand which repos need to be visible. The main project can add use_repo definitions, but as a module there's no way to know which repos the user will want access to.

What's the output of bazel info release?

release 5.0.0rc4

[Wyverald]

The root problem is that labels carry capabilities, but they don't survive the "text" layer that repo rules have to go through to create BUILD files.

In foo/MODULE.bazel:

bazel_dep(name="bar", version="1.0")
ext = use_extension("@bar//:extensions.bzl", "ext")
ext.tag(label = "//my:label")

This allows @bar's extension ext to read the label @foo//my:label, even though @bar normally has no visibility into @foo. And then ext can pass this label on to whatever repo rule it's calling, which means that the repo rule can now read @foo//my:label.

repo_rule = repository_rule(implementation=..., attrs={"label":attr.label()})
def _ext_impl(mctx):
  repo_rule(name="my_repo",label=mctx.modules[0].tag[0].label)

The problem arises when we'd like to read @foo//my:label at BUILD time -- that is, have some BUILD file in @my_repo that can refer to @foo//my:label. The only way to generate a BUILD file is through generating text in repo_rule's impl function. Despite repo_rule's impl function having access to a Label object, it cannot somehow pass this on to the BUILD file without serializing it, at which point it loses the access capability and must go through repo mapping again.

We need to think about how to solve this problem.

[fmeum]

Would it be possible to make the stringification of a Label return a repository-absolute label string that uses canonical repository names, at least with --experimental_enable_bzlmod enabled, and then make all repositories visible to each other unter their canonical repository name? Additional safeguards against Hyrum's law could be to e.g. append an opaque hash to the canonical names and only make the resulting repo names visible.

In general, I find it very difficult to wrap my head around how repository mapped labels and repository rules interact. I am proposing this solution since being able to generate fully absolute label strings from labels that are not subject to repo mappings would perhaps not only solve the current issue, but also simplify the overall process of writing repository rules with bzlmod.

[Wyverald]

Duping against #15593