Skip to content

[9.2.0] Add //tools:tools_for_bazel_subcommands filegroup to vendor mod tidy …#29481

Merged
iancha1992 merged 1 commit intobazelbuild:release-9.2.0from
iancha1992:cp29449
May 8, 2026
Merged

[9.2.0] Add //tools:tools_for_bazel_subcommands filegroup to vendor mod tidy …#29481
iancha1992 merged 1 commit intobazelbuild:release-9.2.0from
iancha1992:cp29449

Conversation

@iancha1992
Copy link
Copy Markdown
Member

…deps (#29445)

bazel vendor //... does not vendor the implicit @buildozer_binary dependency of bazel mod tidy, so a subsequent bazel mod tidy run with --vendor_dir and --nofetch fails with:

ERROR: no such package '@@buildozer++buildozer_binary+buildozer_binary//':
no such package '@@buildozer+//': Vendored repository buildozer+ not found
under the vendor directory and fetching is disabled.

Users currently have to discover and pass the undiscoverable incantation --repo=@@buildozer+ --repo=@@buildozer++buildozer_binary+buildozer_binary.

See #29222 for the full discussion. @fmeum proposed the fix adopted here:

We could add a target under bazel_tools that groups all such tools and that you could add to your vendor pattern list for this purpose.

The reporter confirmed this approach works for their use case.

Add a new public filegroup @bazel_tools//tools:tools_for_bazel_subcommands that groups implicit tool dependencies of Bazel subcommands. Today it contains just @buildozer_binary//:buildozer.exe (required by bazel mod tidy); future subcommands that introduce implicit tool deps can be added here.

Users who run Bazel offline with --vendor_dir and --nofetch can opt in by including the target in their vendor invocation:

bazel vendor //... @bazel_tools//tools:tools_for_bazel_subcommands

This preserves the current behavior for users who don't run bazel mod tidy (no silent expansion of the transitive closure) while giving those who do run it a single, documented target to add to their vendor pattern.

Added test_tools_for_bazel_subcommands in src/test/shell/bazel/bazel_tools_test.sh that queries the new filegroup and asserts buildozer is in its transitive dependencies.

Add `@bazel_tools//tools:tools_for_bazel_subcommands` filegroup that groups implicit tool dependencies of Bazel subcommands (e.g. buildozer for `bazel mod tidy`). Add this target to `bazel vendor` when working offline.

Fixes #29222

Closes #29445.

PiperOrigin-RevId: 910718201
Change-Id: I776833cf65624b67425f85a74d0891316f1ed40e

Description

Motivation

Build API Changes

No

Checklist

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

Release Notes

RELNOTES: None

Commit 29477bc

…deps (bazelbuild#29445)

`bazel vendor //...` does not vendor the implicit `@buildozer_binary` dependency of `bazel mod tidy`, so a subsequent `bazel mod tidy` run with `--vendor_dir` and `--nofetch` fails with:

```
ERROR: no such package '@@buildozer++buildozer_binary+buildozer_binary//':
no such package '@@buildozer+//': Vendored repository buildozer+ not found
under the vendor directory and fetching is disabled.
```

Users currently have to discover and pass the undiscoverable incantation `--repo=@@buildozer+ --repo=@@buildozer++buildozer_binary+buildozer_binary`.

See bazelbuild#29222 for the full discussion. @fmeum proposed the fix adopted here:

> We could add a target under `bazel_tools` that groups all such tools and that you could add to your vendor pattern list for this purpose.

The reporter confirmed this approach works for their use case.

Add a new public filegroup `@bazel_tools//tools:tools_for_bazel_subcommands` that groups implicit tool dependencies of Bazel subcommands. Today it contains just `@buildozer_binary//:buildozer.exe` (required by `bazel mod tidy`); future subcommands that introduce implicit tool deps can be added here.

Users who run Bazel offline with `--vendor_dir` and `--nofetch` can opt in by including the target in their vendor invocation:

```
bazel vendor //... @bazel_tools//tools:tools_for_bazel_subcommands
```

This preserves the current behavior for users who don't run `bazel mod tidy` (no silent expansion of the transitive closure) while giving those who do run it a single, documented target to add to their vendor pattern.

Added `test_tools_for_bazel_subcommands` in `src/test/shell/bazel/bazel_tools_test.sh` that queries the new filegroup and asserts buildozer is in its transitive dependencies.

```
Add `@bazel_tools//tools:tools_for_bazel_subcommands` filegroup that groups implicit tool dependencies of Bazel subcommands (e.g. buildozer for `bazel mod tidy`). Add this target to `bazel vendor` when working offline.
```

Fixes bazelbuild#29222

Closes bazelbuild#29445.

PiperOrigin-RevId: 910718201
Change-Id: I776833cf65624b67425f85a74d0891316f1ed40e
@iancha1992 iancha1992 requested a review from a team as a code owner May 6, 2026 21:04
@iancha1992 iancha1992 added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. awaiting-review PR is awaiting review from an assigned reviewer labels May 6, 2026
@iancha1992 iancha1992 enabled auto-merge May 6, 2026 21:04
@github-actions github-actions Bot added the team-Documentation Documentation improvements that cannot be directly linked to other team labels label May 6, 2026
@iancha1992 iancha1992 added this pull request to the merge queue May 8, 2026
Merged via the queue into bazelbuild:release-9.2.0 with commit 6ec6d86 May 8, 2026
46 checks passed
@github-actions github-actions Bot removed the awaiting-review PR is awaiting review from an assigned reviewer label May 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

team-Documentation Documentation improvements that cannot be directly linked to other team labels team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants