Support external repository labels in package_group by meteorcloudy · Pull Request #28811 · bazelbuild/bazel

meteorcloudy · 2026-02-26T10:44:58Z

Description

This PR enables package_group to correctly interpret labels that include external repositories (e.g., @module//... or @module//:__subpackages__).

Motivation

Previously, PackageSpecification.java strictly required package names to start with //, failing on labels with repository prefixes. This made it impossible to define a package_group that includes packages from other Bzlmod modules. This change leverages Label.parseWithRepoContext to correctly resolve repository mapping and validate package specifications within the context of the repository where the package_group is defined.

Fixes an issue where bazel build would fail when a package_group referenced an external repository in its packages attribute.

Build API Changes

Yes. This change affects the behavior of the package_group rule and the visibility() function in .bzl files.

Has this been discussed in a design doc or issue? No, but the change and impact should be straightforward to understand.
Is the change backward compatible? Yes, it relaxes a restriction that previously caused errors.
If it's a breaking change, what is the migration plan? N/A

Checklist

I have added tests for the new use cases (if any).
I have updated the documentation (if applicable).

Release Notes

RELNOTES: package_group now supports labels with external repositories in the packages attribute.

meteorcloudy · 2026-02-26T12:45:04Z

@brandjon @Wyverald What do you think about this change?

@mkruskal-google needs this for limiting certain abseil targets visibility to a specific new BCR module.

     visibility = [ "@foo//bar:__subpackages__"],

already works when you have a bazel_dep on foo (assuming this dependency won't cause much problem), this change allows such declaration also in package_group.

fmeum · 2026-02-26T13:53:07Z

Does this work with nodep deps? That would resolve concerns about increased dep footprint.

meteorcloudy · 2026-02-27T09:14:12Z

@fmeum Unfortunately no, nodep requires repo_name = None, so the label will be invalid. @mkruskal-google is aware of the dep footprint problem, but it should be fine for this specific case (just a standard C++ library).

meteorcloudy · 2026-02-27T11:46:30Z

FYI @gregestren

Wyverald · 2026-03-02T23:48:07Z

   */
  public static PackageSpecification fromStringForBzlVisibility(
-      RepositoryName repositoryName, String spec) throws EvalException {
+      RepositoryMapping mapper, RepositoryName repositoryName, String spec) throws EvalException {


s/mapper/repoMapping/ ?

Wyverald · 2026-03-02T23:49:23Z

        package_group(
            name = "banana",
-            packages = ["@veggies//:cucumber"],
+            packages = ["@@veggies//cucumber"],


AFAICT there's no test that exercises the repo mapping logic (ie. single @). can you add one?

Good catch, added!

meteorcloudy · 2026-03-05T09:50:13Z

@bazel-io fork 9.1.0

meteorcloudy · 2026-03-05T09:50:30Z

@bazel-io fork 8.7.0

### Description This PR enables `package_group` to correctly interpret labels that include external repositories (e.g., `@module//...` or `@module//:__subpackages__`). ### Motivation Previously, `PackageSpecification.java` strictly required package names to start with `//`, failing on labels with repository prefixes. This made it impossible to define a `package_group` that includes packages from other Bzlmod modules. This change leverages `Label.parseWithRepoContext` to correctly resolve repository mapping and validate package specifications within the context of the repository where the `package_group` is defined. Fixes an issue where bazel build would fail when a `package_group` referenced an external repository in its `packages` attribute. ### Build API Changes Yes. This change affects the behavior of the `package_group` rule and the `visibility()` function in `.bzl` files. 1. Has this been discussed in a design doc or issue? No, but the change and impact should be straightforward to understand. 2. Is the change backward compatible? Yes, it relaxes a restriction that previously caused errors. 3. If it's a breaking change, what is the migration plan? N/A ### Checklist - [x] I have added tests for the new use cases (if any). - [ ] I have updated the documentation (if applicable). ### Release Notes RELNOTES: `package_group` now supports labels with external repositories in the `packages` attribute. Closes bazelbuild#28811. PiperOrigin-RevId: 878957471 Change-Id: Ic84df870374fb8c6f6f24d6fdff388d909750469

meteorcloudy · 2026-03-05T12:38:07Z

@bazel-io fork 9.0.1

### Description This PR enables `package_group` to correctly interpret labels that include external repositories (e.g., `@module//...` or `@module//:__subpackages__`). ### Motivation Previously, `PackageSpecification.java` strictly required package names to start with `//`, failing on labels with repository prefixes. This made it impossible to define a `package_group` that includes packages from other Bzlmod modules. This change leverages `Label.parseWithRepoContext` to correctly resolve repository mapping and validate package specifications within the context of the repository where the `package_group` is defined. Fixes an issue where bazel build would fail when a `package_group` referenced an external repository in its `packages` attribute. ### Build API Changes Yes. This change affects the behavior of the `package_group` rule and the `visibility()` function in `.bzl` files. 1. Has this been discussed in a design doc or issue? No, but the change and impact should be straightforward to understand. 2. Is the change backward compatible? Yes, it relaxes a restriction that previously caused errors. 3. If it's a breaking change, what is the migration plan? N/A ### Checklist - [x] I have added tests for the new use cases (if any). - [ ] I have updated the documentation (if applicable). ### Release Notes RELNOTES: `package_group` now supports labels with external repositories in the `packages` attribute. Closes bazelbuild#28811. PiperOrigin-RevId: 878957471 Change-Id: Ic84df870374fb8c6f6f24d6fdff388d909750469

This PR enables `package_group` to correctly interpret labels that include external repositories (e.g., `@module//...` or `@module//:__subpackages__`). Previously, `PackageSpecification.java` strictly required package names to start with `//`, failing on labels with repository prefixes. This made it impossible to define a `package_group` that includes packages from other Bzlmod modules. This change leverages `Label.parseWithRepoContext` to correctly resolve repository mapping and validate package specifications within the context of the repository where the `package_group` is defined. Fixes an issue where bazel build would fail when a `package_group` referenced an external repository in its `packages` attribute. Yes. This change affects the behavior of the `package_group` rule and the `visibility()` function in `.bzl` files. 1. Has this been discussed in a design doc or issue? No, but the change and impact should be straightforward to understand. 2. Is the change backward compatible? Yes, it relaxes a restriction that previously caused errors. 3. If it's a breaking change, what is the migration plan? N/A - [x] I have added tests for the new use cases (if any). - [ ] I have updated the documentation (if applicable). RELNOTES: `package_group` now supports labels with external repositories in the `packages` attribute. Closes bazelbuild#28811. PiperOrigin-RevId: 878957471 Change-Id: Ic84df870374fb8c6f6f24d6fdff388d909750469

…28895) ### Description This PR enables `package_group` to correctly interpret labels that include external repositories (e.g., `@module//...` or `@module//:__subpackages__`). ### Motivation Previously, `PackageSpecification.java` strictly required package names to start with `//`, failing on labels with repository prefixes. This made it impossible to define a `package_group` that includes packages from other Bzlmod modules. This change leverages `Label.parseWithRepoContext` to correctly resolve repository mapping and validate package specifications within the context of the repository where the `package_group` is defined. Fixes an issue where bazel build would fail when a `package_group` referenced an external repository in its `packages` attribute. ### Build API Changes Yes. This change affects the behavior of the `package_group` rule and the `visibility()` function in `.bzl` files. 1. Has this been discussed in a design doc or issue? No, but the change and impact should be straightforward to understand. 2. Is the change backward compatible? Yes, it relaxes a restriction that previously caused errors. 3. If it's a breaking change, what is the migration plan? N/A ### Checklist - [x] I have added tests for the new use cases (if any). - [ ] I have updated the documentation (if applicable). ### Release Notes RELNOTES: `package_group` now supports labels with external repositories in the `packages` attribute. Closes #28811. PiperOrigin-RevId: 878957471 Change-Id: Ic84df870374fb8c6f6f24d6fdff388d909750469 Commit dfe9326 Co-authored-by: Yun Peng <[email protected]>

…28893) ### Description This PR enables `package_group` to correctly interpret labels that include external repositories (e.g., `@module//...` or `@module//:__subpackages__`). ### Motivation Previously, `PackageSpecification.java` strictly required package names to start with `//`, failing on labels with repository prefixes. This made it impossible to define a `package_group` that includes packages from other Bzlmod modules. This change leverages `Label.parseWithRepoContext` to correctly resolve repository mapping and validate package specifications within the context of the repository where the `package_group` is defined. Fixes an issue where bazel build would fail when a `package_group` referenced an external repository in its `packages` attribute. ### Build API Changes Yes. This change affects the behavior of the `package_group` rule and the `visibility()` function in `.bzl` files. 1. Has this been discussed in a design doc or issue? No, but the change and impact should be straightforward to understand. 2. Is the change backward compatible? Yes, it relaxes a restriction that previously caused errors. 3. If it's a breaking change, what is the migration plan? N/A ### Checklist - [x] I have added tests for the new use cases (if any). - [ ] I have updated the documentation (if applicable). ### Release Notes RELNOTES: `package_group` now supports labels with external repositories in the `packages` attribute. Closes #28811. PiperOrigin-RevId: 878957471 Change-Id: Ic84df870374fb8c6f6f24d6fdff388d909750469 Commit dfe9326 Co-authored-by: Yun Peng <[email protected]>

meteorcloudy · 2026-03-06T13:10:07Z

Rolled back at 4eac06f due to internal breakages.

meteorcloudy · 2026-03-06T13:10:37Z

Likely we just need to clean up the depot, so we don't have to rollback in release branches.

meteorcloudy requested a review from a team as a code owner February 26, 2026 10:44

meteorcloudy requested review from gregestren and removed request for a team February 26, 2026 10:44

github-actions Bot added team-Configurability platforms, toolchains, cquery, select(), config transitions awaiting-review PR is awaiting review from an assigned reviewer labels Feb 26, 2026

meteorcloudy marked this pull request as draft February 26, 2026 10:45

meteorcloudy removed the request for review from gregestren February 26, 2026 10:45

meteorcloudy force-pushed the fix-package-group-external-repos branch 2 times, most recently from 2ec99a5 to 2b4c509 Compare February 26, 2026 12:40

meteorcloudy marked this pull request as ready for review February 27, 2026 11:46

meteorcloudy requested review from Wyverald and gregestren February 27, 2026 11:47

Wyverald approved these changes Mar 2, 2026

View reviewed changes

meteorcloudy added 3 commits March 4, 2026 13:41

Support external repository labels in package_group

a437d5d

Fix

4832560

Add tests

bced873

meteorcloudy force-pushed the fix-package-group-external-repos branch from 2b4c509 to bced873 Compare March 4, 2026 14:02

Wyverald approved these changes Mar 4, 2026

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 Mar 4, 2026

bazel-docs-pull-requestor Bot mentioned this pull request Mar 4, 2026

docs preview: bazelbuild/bazel#28811 bazel-contrib/bazel-docs#245

Closed

alan707 mentioned this pull request Mar 5, 2026

fix: remove broad lib/** pattern from upstream change detection bazel-contrib/bazel-docs#247

Merged

This was referenced Mar 5, 2026

[9.1.0] Support external repository labels in package_group #28891

Closed

[8.7.0] Support external repository labels in package_group #28892

Closed

copybara-service Bot closed this in dfe9326 Mar 5, 2026

github-actions Bot removed the awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally label Mar 5, 2026

bazel-io mentioned this pull request Mar 5, 2026

[9.1.0] Support external repository labels in package_group (https://github.com/bazelbuild/bazel/pull/28811) #28893

Merged

2 tasks

bazel-io mentioned this pull request Mar 5, 2026

[9.0.1] Support external repository labels in package_group #28894

Closed

bazel-io mentioned this pull request Mar 5, 2026

[9.0.1] Support external repository labels in package_group (https://github.com/bazelbuild/bazel/pull/28811) #28895

Merged

2 tasks

Conversation

meteorcloudy commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Motivation

Build API Changes

Checklist

Release Notes

Uh oh!

meteorcloudy commented Feb 26, 2026

Uh oh!

fmeum commented Feb 26, 2026

Uh oh!

meteorcloudy commented Feb 27, 2026

Uh oh!

meteorcloudy commented Feb 27, 2026

Uh oh!

Wyverald Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

meteorcloudy Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

Wyverald Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

meteorcloudy Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

meteorcloudy commented Mar 5, 2026

Uh oh!

meteorcloudy commented Mar 5, 2026

Uh oh!

meteorcloudy commented Mar 5, 2026

Uh oh!

meteorcloudy commented Mar 6, 2026

Uh oh!

meteorcloudy commented Mar 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

meteorcloudy commented Feb 26, 2026 •

edited

Loading