Add `repository_ctx.original_name` by fmeum · Pull Request #25121 · bazelbuild/bazel

fmeum · 2025-01-29T09:22:43Z

This new attribute contains the original value of the name attribute at the instantiation site of the repo rule (e.g., rctx.original_name would be foo if rctx.name is +ext+foo).

Fixes #24467

fmeum · 2025-01-29T09:23:10Z

+          "The name that was originally specified as the 'name' attribute when this repository rule was instantiated. This name is not necessarily unique among external repositories (see 'name').")
+  public String getOriginalName() {
+    String originalName = (String) rule.getAttr("$original_name", Type.STRING);
+    // The original name isn't set for WORKSPACE-defined repositories as well as repositories


Are these still a thing at HEAD? What's our strategy for backporting this, should I add new tests to the backports?

fmeum · 2025-01-29T09:57:29Z

@Wyverald @meteorcloudy Since rulesets still have to support WORKSPACE at this point, in which rctx.attr.name is a valid apparent repo name, I wonder whether we should instead make it so that:

rctx.name returns the canonical repo name (current behavior)
rctx.attr.name returns the original value of the name attribute (which equals ctx.name for WORKSPACE repos)

We wouldn't be able to cherry-pick the change, but for backwards compatibility users already need to resort to canonical repo name parsing where necessary (e.g. repo rules meant to be used with use_repo_rule). Advantages are that:

It's pretty self-explanatory that rctx.attr.name returns the value of the attribute unmodified.
We avoid introducing a third way to get a name for a repo rule.

Implementing this wouldn't be difficult, we could just monkey patch the StructImpl returned by rctx.attr to return the value of rctx.attr.$original_name for rctx.attr.name if set.

meteorcloudy · 2025-01-29T11:16:56Z

I don't have strong preference on either way, I trust you and @Wyverald to make the best decision.

But we should definitely document the best practices somewhere, I can follow up on that.

Wyverald · 2025-01-29T21:21:40Z

Since rulesets still have to support WORKSPACE at this point, in which rctx.attr.name is a valid apparent repo name, [...]

I don't quite follow this logic -- currently, in either Bzlmod or WORKSPACE, it's always true that rctx.name == rctx.attr.name. Changing the behavior of either one at this point would be breaking, and for unclear benefits.

Although TBH I agree that if we were to start from scratch, having the rctx.name vs rctx.attr.name dichotomy would've been nice.

fmeum · 2025-01-29T23:40:48Z

I don't quite follow this logic -- currently, in either Bzlmod or WORKSPACE, it's always true that rctx.name == rctx.attr.name

They are equal today, but I doubt anyone relies on that property. What I (badly) described above is that a repo rule today must be prepared to receive both foo (with WORKSPACE) and +ext+foo (with Bzlmod) in whichever of the two it uses. Changing one of them to be of the form foo all the time thus shouldn't be that breaking in practice.

If you don't think that's doable, I'm also happy to go with the approach that's currently implemented by this PR.

Wyverald · 2025-01-30T00:16:11Z

What I meant is that, technically, a repo rule could be relying on the semantics that rctx.name (and rctx.attr.name) refer to the canonical name of the repo (which has always been true in Bzlmod or WORKSPACE). For such a repo rule, it doesn't matter whether rctx.name is foo or +repo_rules3_foo or 8dwfu91e; it just needs @@${rctx.name}//:blah to be a valid label referring to itself.

With that said, I am struggling to think of a realistic example of such a repo rule... but IMO introducing an explicit API could avoid some headache in the future. Not a super strong opinion.

fmeum · 2025-01-30T12:31:08Z

We aren't locking us in, we could still change the behavior of ctx.attr.name in the future. I'm okay with the PR as is.

fmeum · 2025-01-30T22:30:14Z

@bazel-io fork 8.1.0

iancha1992 · 2025-01-30T23:00:56Z

@fmeum can you please resolve the conflicts? Thanks

This new attribute contains the original value of the `name` attribute at the instantiation site of the repo rule (e.g., `rctx.original_name` would be `foo` if `rctx.name` is `+ext+foo`). # Conflicts: # src/test/java/com/google/devtools/build/lib/bazel/bzlmod/ModuleExtensionResolutionTest.java

fmeum · 2025-01-31T08:38:35Z

@iancha1992 Done!

satyanandak · 2025-01-31T10:18:30Z

@fmeum could you please take a look at the presubmit failures?

fmeum · 2025-01-31T10:22:03Z

@satyanandak Fixed

This new attribute contains the original value of the `name` attribute at the instantiation site of the repo rule (e.g., `rctx.original_name` would be `foo` if `rctx.name` is `+ext+foo`). Fixes bazelbuild#24467 Closes bazelbuild#25121. RELNOTES: Added `repository_ctx.original_name`, which contains the original value of the `name` attribute as specified at the repo rule call site. PiperOrigin-RevId: 722731393 Change-Id: I2f7dada0c44b6bd4c0d2622fa1e97223382a8547 (cherry picked from commit 8bcfb06)

This new attribute contains the original value of the `name` attribute at the instantiation site of the repo rule (e.g., `rctx.original_name` would be `foo` if `rctx.name` is `+ext+foo`). Fixes #24467 Closes #25121. RELNOTES: Added `repository_ctx.original_name`, which contains the original value of the `name` attribute as specified at the repo rule call site. PiperOrigin-RevId: 722731393 Change-Id: I2f7dada0c44b6bd4c0d2622fa1e97223382a8547 (cherry picked from commit 8bcfb06) Fixes #25147

meteorcloudy · 2025-09-19T08:30:26Z

@bazel-io fork 7.7.0

This new attribute contains the original value of the `name` attribute at the instantiation site of the repo rule (e.g., `rctx.original_name` would be `foo` if `rctx.name` is `+ext+foo`). Fixes bazelbuild#24467 Closes bazelbuild#25121. RELNOTES: Added `repository_ctx.original_name`, which contains the original value of the `name` attribute as specified at the repo rule call site. PiperOrigin-RevId: 722731393 Change-Id: I2f7dada0c44b6bd4c0d2622fa1e97223382a8547 (cherry picked from commit 8bcfb06) Fixes bazelbuild#25147

Fixes the breakage in `@rules_magic_leaflet` from the previous commit by using two mechanisms for generating a default target name in a repository rule. - Bazel 8.1.1 added `repository_ctx.original_name` to facilitate the generation of default repo target names. - For earlier Bazels, the wrapper macro and `default_target_name` attribute pass through the original repo name for when `repository_ctx.original_name` isn't available. Using both for now provides backwards and forward compatibility across Bazel versions while avoiding the need for parsing the canonical repo name format. The canonical repo name format has changed several times, making this a very practical concern. For more background, see: - bazelbuild/bazel#24467 - bazelbuild/bazel#25121 And as for why we recommend using Bazel 8.1.1 or later, instead of 8.1.0 when `repository_ctx.original_name` first appeared: - bazelbuild/bazel#25286

This new attribute contains the original value of the `name` attribute at the instantiation site of the repo rule (e.g., `rctx.original_name` would be `foo` if `rctx.name` is `+ext+foo`). Fixes #24467 Closes #25121. RELNOTES: Added `repository_ctx.original_name`, which contains the original value of the `name` attribute as specified at the repo rule call site. PiperOrigin-RevId: 722731393 Change-Id: I2f7dada0c44b6bd4c0d2622fa1e97223382a8547 (cherry picked from commit 8bcfb06) Fixes #27033 Context: this would help google-ml-infra/rules_ml_toolchain#84 --------- Co-authored-by: Fabian Meumertzheim <[email protected]>

Fixes the breakage in `@rules_magic_leaflet` from the previous commit by using two mechanisms for generating a default target name in a repository rule. - Bazel 8.1.1 added `repository_ctx.original_name` to facilitate the generation of default repo target names. - For earlier Bazels, the wrapper macro and `default_target_name` attribute pass through the original repo name for when `repository_ctx.original_name` isn't available. Using both for now provides backwards and forward compatibility across Bazel versions while avoiding the need for parsing the canonical repo name format. The canonical repo name format has changed several times, making this a very practical concern. For more background, see: - bazelbuild/bazel#24467 - bazelbuild/bazel#25121 And as for why we recommend using Bazel 8.1.1 or later, instead of 8.1.0 when `repository_ctx.original_name` first appeared: - bazelbuild/bazel#25286 --- However, the build now breaks with: ```txt ERROR: external/rules_magic+/toolchains/BUILD:17:22: no such package '@@rules_magic+//external': BUILD file not found in directory 'external' of external repository @@rules_magic+. Add a BUILD file to a directory to mark it as a package. and referenced by '@@rules_magic+//toolchains:default_settings_toolchain_impl' ERROR: Analysis of target '//:default-values' failed; build aborted: Analysis failed ``` This is because `native.bind` doesn't work under Bzlmod. We're not yet hitting the error indicating that `native.bind` is no longer available, but that the artifical `//external` package no longer exists.

Fixes the breakage in `@rules_magic_leaflet` from the previous commit by using two mechanisms for generating a default target name in a repository rule. - Bazel 7.7.0 and 8.1.1 provide `repository_ctx.original_name` to facilitate the generation of default repo target names. - For earlier Bazels, the wrapper macro and `default_target_name` attribute pass through the original repo name for when `repository_ctx.original_name` isn't available. Using both for now provides backwards and forward compatibility across Bazel versions while avoiding the need for parsing the canonical repo name format. The canonical repo name format has changed several times, making this a very practical concern. For more background, see: - bazelbuild/bazel#24467 - bazelbuild/bazel#25121 And as for why we recommend using Bazel 8.1.1 or later, instead of 8.1.0 when `repository_ctx.original_name` first appeared: - bazelbuild/bazel#25286 --- However, the build now breaks with: ```txt ERROR: external/rules_magic+/toolchains/BUILD:17:22: no such package '@@rules_magic+//external': BUILD file not found in directory 'external' of external repository @@rules_magic+. Add a BUILD file to a directory to mark it as a package. and referenced by '@@rules_magic+//toolchains:default_settings_toolchain_impl' ERROR: Analysis of target '//:default-values' failed; build aborted: Analysis failed ``` This is because `native.bind` doesn't work under Bzlmod. We're not yet hitting the error indicating that `native.bind` is no longer available, but that the artifical `//external` package no longer exists.

Fixes the breakage in `@rules_magic_leaflet` from the previous commit by using two mechanisms for generating a default target name in a repository rule. - Bazel 8.1.1 added `repository_ctx.original_name` to facilitate the generation of default repo target names. - For earlier Bazels, the wrapper macro and `default_target_name` attribute pass through the original repo name for when `repository_ctx.original_name` isn't available. Using both for now provides backwards and forward compatibility across Bazel versions while avoiding the need for parsing the canonical repo name format. The canonical repo name format has changed several times, making this a very practical concern. For more background, see: - bazelbuild/bazel#24467 - bazelbuild/bazel#25121 And as for why we recommend using Bazel 8.1.1 or later, instead of 8.1.0 when `repository_ctx.original_name` first appeared: - bazelbuild/bazel#25286 --- However, the build now breaks with: ```txt ERROR: external/rules_magic+/toolchains/BUILD:17:22: no such package '@@rules_magic+//external': BUILD file not found in directory 'external' of external repository @@rules_magic+. Add a BUILD file to a directory to mark it as a package. and referenced by '@@rules_magic+//toolchains:default_settings_toolchain_impl' ERROR: Analysis of target '//:default-values' failed; build aborted: Analysis failed ``` This is because `native.bind` doesn't work under Bzlmod. We're not yet hitting the error indicating that `native.bind` is no longer available, but that the artifical `//external` package no longer exists.

Fixes the breakage in `@rules_magic_leaflet` from the previous commit by using two mechanisms for generating a default target name in a repository rule. - Bazel 7.7.0 and 8.1.1 provide `repository_ctx.original_name` to facilitate the generation of default repo target names. - For earlier Bazels, the wrapper macro and `default_target_name` attribute pass through the original repo name for when `repository_ctx.original_name` isn't available. Using both for now provides backwards and forward compatibility across Bazel versions while avoiding the need for parsing the canonical repo name format. The canonical repo name format has changed several times, making this a very practical concern. For more background, see: - bazelbuild/bazel#24467 - bazelbuild/bazel#25121 As for why we recommend using Bazel 8.1.1 or later, instead of 8.1.0 when `repository_ctx.original_name` first appeared: - bazelbuild/bazel#25286 And as for why `rules_kotlin` appears now in `MODULE.bazel.lock`, I have no idea. --- However, the build now breaks with the following errors. Bazel 7 reports: ```txt ERROR: no such package 'external': the WORKSPACE file is disabled via --noenable_workspace ERROR: external/rules_magic+/magic/BUILD:38:22: no such package 'external': the WORKSPACE file is disabled via --noenable_workspace and referenced by '@@rules_magic+//magic:default_settings_toolchain_impl' ERROR: Analysis of target '//:default-values' failed; build aborted: Analysis failed ``` Bazel 8 reports: ```txt ERROR: no such package '@@rules_magic+//external': BUILD file not found in directory 'external' of external repository @@rules_magic+. Add a BUILD file to a directory to mark it as a package. ERROR: .../external/rules_magic+/magic/BUILD:38:22: no such package '@@rules_magic+//external': BUILD file not found in directory 'external' of external repository @@rules_magic+. Add a BUILD file to a directory to mark it as a package. and referenced by '@@rules_magic+//magic:default_settings_toolchain_impl' ERROR: Analysis of target '//:default-values' failed; build aborted: Analysis failed ``` This is because `native.bind` doesn't work under Bzlmod. We're not yet hitting the error indicating that `native.bind` is no longer available, but that the artifical `//external` package no longer exists.

Fixes the breakage in `@rules_magic_leaflet` from the previous commit by using two mechanisms for generating a default target name in a repository rule. - Bazel 8.1.1 added `repository_ctx.original_name` to facilitate the generation of default repo target names. - For earlier Bazels, the wrapper macro and `default_target_name` attribute pass through the original repo name for when `repository_ctx.original_name` isn't available. Using both for now provides backwards and forward compatibility across Bazel versions while avoiding the need for parsing the canonical repo name format. The canonical repo name format has changed several times, making this a very practical concern. For more background, see: - bazelbuild/bazel#24467 - bazelbuild/bazel#25121 And as for why we recommend using Bazel 8.1.1 or later, instead of 8.1.0 when `repository_ctx.original_name` first appeared: - bazelbuild/bazel#25286 --- However, the build now breaks with: ```txt ERROR: external/rules_magic+/toolchains/BUILD:17:22: no such package '@@rules_magic+//external': BUILD file not found in directory 'external' of external repository @@rules_magic+. Add a BUILD file to a directory to mark it as a package. and referenced by '@@rules_magic+//toolchains:default_settings_toolchain_impl' ERROR: Analysis of target '//:default-values' failed; build aborted: Analysis failed ``` This is because `native.bind` doesn't work under Bzlmod. We're not yet hitting the error indicating that `native.bind` is no longer available, but that the artifical `//external` package no longer exists.

Fixes the breakage in `@rules_magic_leaflet` from the previous commit by using two mechanisms for generating a default target name in a repository rule. - Bazel 7.7.0 and 8.1.1 provide `repository_ctx.original_name` to facilitate the generation of default repo target names. - For earlier Bazels, the wrapper macro and `default_target_name` attribute pass through the original repo name for when `repository_ctx.original_name` isn't available. Using both for now provides backwards and forward compatibility across Bazel versions while avoiding the need for parsing the canonical repo name format. The canonical repo name format has changed several times, making this a very practical concern. For more background, see: - bazelbuild/bazel#24467 - bazelbuild/bazel#25121 As for why we recommend using Bazel 8.1.1 or later, instead of 8.1.0 when `repository_ctx.original_name` first appeared: - bazelbuild/bazel#25286 And as for why `rules_kotlin` appears now in `MODULE.bazel.lock`, I have no idea. --- However, the build now breaks with the following errors. Bazel 7 reports: ```txt ERROR: no such package 'external': the WORKSPACE file is disabled via --noenable_workspace ERROR: external/rules_magic+/magic/BUILD:38:22: no such package 'external': the WORKSPACE file is disabled via --noenable_workspace and referenced by '@@rules_magic+//magic:default_settings_toolchain_impl' ERROR: Analysis of target '//:default-values' failed; build aborted: Analysis failed ``` Bazel 8 reports: ```txt ERROR: no such package '@@rules_magic+//external': BUILD file not found in directory 'external' of external repository @@rules_magic+. Add a BUILD file to a directory to mark it as a package. ERROR: .../external/rules_magic+/magic/BUILD:38:22: no such package '@@rules_magic+//external': BUILD file not found in directory 'external' of external repository @@rules_magic+. Add a BUILD file to a directory to mark it as a package. and referenced by '@@rules_magic+//magic:default_settings_toolchain_impl' ERROR: Analysis of target '//:default-values' failed; build aborted: Analysis failed ``` This is because `native.bind` doesn't work under Bzlmod. We're not yet hitting the error indicating that `native.bind` is no longer available, but that the artifical `//external` package no longer exists.

fmeum requested review from Wyverald and meteorcloudy as code owners January 29, 2025 09:22

github-actions Bot added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. awaiting-review PR is awaiting review from an assigned reviewer labels Jan 29, 2025

fmeum commented Jan 29, 2025

View reviewed changes

Wyverald approved these changes Jan 30, 2025

View reviewed changes

Wyverald added awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally and removed awaiting-review PR is awaiting review from an assigned reviewer labels Jan 30, 2025

bazel-io mentioned this pull request Jan 30, 2025

[8.1.0] Add repository_ctx.original_name #25147

Closed

fmeum added 2 commits January 31, 2025 09:33

Fix tests and update docs

4821343

fmeum force-pushed the 24467-original-name branch from f992e42 to 6c65262 Compare January 31, 2025 08:38

Resolve conflicts

a50b755

fmeum force-pushed the 24467-original-name branch from 6c65262 to a50b755 Compare January 31, 2025 10:21

copybara-service Bot closed this in 8bcfb06 Feb 3, 2025

github-actions Bot removed the awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally label Feb 3, 2025

fmeum deleted the 24467-original-name branch February 3, 2025 19:49

fmeum mentioned this pull request Feb 4, 2025

[8.1.0] Add repository_ctx.original_name #25191

Merged

mbland mentioned this pull request Feb 4, 2025

New repository_ctx.original_name produces "canonical reproducible" warnings #25192

Closed

mbland mentioned this pull request Feb 14, 2025

repository_ctx.original_name is the empty string under WORKSPACE #25286

Closed

bazel-io mentioned this pull request Sep 19, 2025

[7.7.0] Add repository_ctx.original_name #27033

Closed

meteorcloudy mentioned this pull request Sep 19, 2025

[7.7.0] Add repository_ctx.original_name #27034

Merged

Conversation

fmeum commented Jan 29, 2025

Uh oh!

fmeum Jan 29, 2025

Choose a reason for hiding this comment

Uh oh!

fmeum commented Jan 29, 2025

Uh oh!

meteorcloudy commented Jan 29, 2025

Uh oh!

Wyverald commented Jan 29, 2025

Uh oh!

fmeum commented Jan 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Wyverald commented Jan 30, 2025

Uh oh!

fmeum commented Jan 30, 2025

Uh oh!

fmeum commented Jan 30, 2025

Uh oh!

iancha1992 commented Jan 30, 2025

Uh oh!

fmeum commented Jan 31, 2025

Uh oh!

satyanandak commented Jan 31, 2025

Uh oh!

fmeum commented Jan 31, 2025

Uh oh!

meteorcloudy commented Sep 19, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

fmeum commented Jan 29, 2025 •

edited

Loading