refactor: use gazelle for bzl_library management#3852
Conversation
…naging bzl_library targets to automate dependency tracking and ensure Starlark API consistency. This is achieved by integrating the Gazelle plugin, applying custom patches to resolve complex name clashes and external repository overrides, and manually migrating the sphinxdocs submodule.
…dback. Move the gazelle_binary to tools/private to avoid production dependencies, clean up package visibilities, interleave public aliases alphabetically, and restore necessary stardoc name collision shields.
…clashing Starlark files to simplify build structure. Move all Gazelle loads and targets to tools/private/gazelle, and rename private stamp and sentinel Starlark files to stamp_impl and sentinel_impl to naturally avoid target name collisions without manual overrides.
…bpackages. Add explicit visibility attributes to internal_dev_deps, internal_dev_setup, and version targets to prevent them from being public by default.
rickeylev
changed the title
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request renames public bzl_library targets from {foo}_bzl to {foo} to align with Gazelle naming conventions, while keeping deprecated aliases for backwards compatibility. It also configures Gazelle for Starlark files, applies a patch to bazel_skylib_gazelle_plugin, and adds numerous missing bzl_library targets across the repository to improve build and documentation coverage. Feedback on the changes includes removing leftover debug logging (JETSKI_DEBUG) in the applied patch, avoiding a dependency on a private target of @rules_testing in tests/BUILD.bazel, and correcting the deps of the :test_helpers bzl_library target in tests/python_bzlmod_ext/BUILD.bazel which incorrectly references test targets.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
…nd add safety keep shields to public test-related targets. This ensures test targets are not incorrectly managed or pruned by Gazelle.
…-library # Conflicts: # docs/BUILD.bazel # python/features.bzl # python/private/pypi/BUILD.bazel # python/uv/private/BUILD.bazel
…n the root BUILD file. This documents the Gazelle suffix-stripping bug for future maintainers.
…ted changes in tests and examples directories to match upstream. This ensures these directories remain completely untouched by the Gazelle migration.
Update build targets to align with upgraded external rulesets (rules_cc, platforms, protobuf) and restore compatibility aliases for renamed public targets.
dougthor42
left a comment
dougthor42
left a comment
There was a problem hiding this comment.
Unfortunately, gazelle has strong opinions about target names: it forces
{foo}names and doesn't allow{foo}_bzlnames. Trying to make it do so requires quite a bit of gazelle directives.
I found similar issues when trying to gazelle-ify our bzl_library stuff in QAI 😞.
General question: Did you delete most files and have Gazelle remake them? Ordering has changed and whatnot.
Looks like a lot of build failures, too.
| @@ -0,0 +1,22 @@ | |||
| # Copyright 2024 The Bazel Authors. All rights reserved. | |||
There was a problem hiding this comment.
- I thought we didn't need copyrights anymore?
- Year is wrong
…rt targets. This ensures the tests/ directory remains completely pristine and untouched by custom targets, while satisfying Bazel loading phase requirements.
|
I saw one |
|
Yeah, slopbot is having a hard time with this. Feel free to drop random comments on things you see so they don't get forgotten about.
+1
Ugh, I know. It really insists on adding them. agents.md says not to. Very open to ideas on how to stop it from doing this. |
Apply user feedback to the Gazelle migration plan, add proper YAML front matter to the always_on rule, and introduce a new skill to guide the creation and formatting of agent rules.
Remove dependency patches and overrides, restrict config_settings visibility, add compatibility aliases for extensions and local_toolchains, exclude legacy common paths, sort python targets, and finalize the migration plan with the public targets list.
Expose py_cc_toolchain and py_cc_toolchain_info bzl_library targets to the public to match their deprecated aliases, and add them to the public targets list in the plan.
3 participants
To make it easier to manage the many bzl_library targets we have, switch to using
gazelle to do so.
Unfortunately, gazelle has strong opinions about target names: it forces
{foo}names and doesn't allow{foo}_bzlnames. Trying to make it do so requiresquite a bit of gazelle directives.
Instead, rename all the internal targets, but create aliases for public targets.