Support repository name mappings in extension_metadata

[malt3]

Allow root_module_direct_deps and root_module_direct_dev_deps to accept dicts mapping module-local names to extension-exported names, in addition to the existing list format. This enables modules to import repositories under different names than those created by the extension.

When specified as a dict (e.g., {"my_foo": "ext_foo"}), bazel mod tidy will generate use_repo commands with the mapping syntax (my_foo = "ext_foo").

Context: https://bazelbuild.slack.com/archives/C09E58X3AQ7/p1764934858912079

Stacked on bazelbuild/buildtools#1427. I'll add some more tests in mod_command_test.py once the buildozer change is merged and available for bazel mod tidy.

RELNOTES: module_ctx.extension_metadata now accepts dictionary mappings in the root_module_direct_deps and root_module_direct_dev_deps parameters. Keys are the module‑local repository names and values are the names exported by the extension. When such a mapping is provided, bazel mod tidy generates use_repo calls with the mapping syntax (e.g., my_foo = "ext_foo"), letting modules import an extension’s repositories under custom local names.

[gemini-code-assist]

Summary of Changes

Hello @malt3, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances Bazel's Bzlmod system by introducing support for flexible repository name mappings within module extension metadata. It allows module extensions to define how their exported repositories are named when imported by the root module, enabling custom local names for dependencies. This change improves the bazel mod tidy command's ability to generate precise use_repo commands, adapting to user-defined naming conventions and preventing conflicts.

Highlights

• Repository Name Mappings: The root_module_direct_deps and root_module_direct_dev_deps parameters in extension_metadata now support dictionary inputs, allowing modules to import repositories under different names than those exported by the extension.
• Flexible use_repo Generation: When dictionaries are used for dependency declarations, bazel mod tidy will generate use_repo commands with the mapping syntax (e.g., my_foo = "ext_foo"), providing greater control over module-local repository names.
• Enhanced Validation: Validation logic has been updated to correctly handle dictionary mappings, ensuring disjointness of both module-local names and extension-exported names between direct and dev dependencies, and validating repository names for both keys and values in the dictionary.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request adds support for repository name mappings in extension_metadata, allowing root_module_direct_deps and root_module_direct_dev_deps to accept dictionaries. The changes look good and cover the new functionality well, including updates to documentation and comprehensive tests. I have two main points of feedback: one critical issue regarding a potential crash due to duplicate imports, and one medium-severity suggestion to optimize a loop for better performance.

[malt3]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds support for repository name mappings in extension_metadata, allowing root_module_direct_deps and root_module_direct_dev_deps to accept dictionaries. This is a great feature that enhances flexibility. The implementation is solid, with good validation and test coverage. I've found one area in LockfileModuleExtensionMetadata.java where code can be refactored to improve efficiency and reduce duplication by processing proxies in a single pass.

[malt3]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces support for repository name mappings in extension_metadata by allowing root_module_direct_deps and root_module_direct_dev_deps to accept dictionaries. This is a valuable enhancement for module authors, providing more flexibility in naming repositories.

The implementation is well-structured, with clear separation of concerns. The changes to the Starlark API and documentation are thorough. The validation logic for the new dictionary format is robust, covering various edge cases such as duplicate names and invalid entries. The accompanying tests are also comprehensive.

I've found one critical bug in the generateFixup logic that would cause bazel mod tidy to behave incorrectly for dev dependencies. The fix is straightforward. After addressing this, the PR should be in great shape.

[malt3]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds support for repository name mappings in extension_metadata, allowing modules to import repositories under different names. The implementation is thorough, covering changes to metadata handling, fixup generation, and Starlark API documentation. The new logic correctly handles both list-style and dictionary-style dependencies, including validation and error reporting for various edge cases. The accompanying tests are comprehensive and cover the new functionality well. I have a few minor suggestions for optimization, but overall, this is a solid contribution.

[malt3]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds support for repository name mappings in extension_metadata by allowing root_module_direct_deps and root_module_direct_dev_deps to be specified as dictionaries. This is a valuable feature that increases the flexibility of module extensions.

The implementation is well-executed across the affected files. The logic for parsing, validation, and generating bazel mod tidy fixups has been updated thoughtfully to handle the new mapping capabilities. The Starlark API changes are clear, and the new tests provide good coverage for the new functionality and edge cases.

Overall, this is a high-quality change. I have one minor suggestion to remove a bit of dead code to improve maintainability.

[malt3]

@Wyverald and @meteorcloudy if we all agree that this is a good idea, could we get some help to get the buildozer PR merged and released so that this can still make it in time for Bazel 9?

As @fmeum mentioned, this can help solve many of the reasons why people would want isolated extensions (and subsequently could potentially allow us to get rid of true isolated extensions).

[fmeum]

@bazel-io fork 9.0.0