借助模块扩展，用户可以通过从依赖项图中的模块读取输入数据、执行必要的逻辑来解析依赖项，最后通过调用代码库规则创建代码库来扩展模块系统。这些扩展程序 具有类似于代码库规则的功能，这使它们能够执行文件 I/O、 发送网络请求等等。除此之外，它们还可让 Bazel 与其他软件包管理系统交互 使用 Bazel 模块构建的依赖关系图。
您可以在 .bzl 文件中定义模块扩展，就像定义代码库规则一样。它们是
不能直接调用相反，每个模块都会指定一段称为“标记”的数据
以供扩展程序读取Bazel 会先运行模块解析，然后再评估任何扩展程序。该扩展程序会读取整个
依赖关系图
扩展程序使用情况
扩展程序托管在 Bazel 模块本身中。要在
模块，请先在托管扩展程序的模块上添加一个 bazel_dep，然后
调用 use_extension 内置函数
以将其纳入范围。请考虑以下示例，其中一段代码来自
MODULE.bazel 文件，以使用“maven”在
rules_jvm_external
模块：
bazel_dep(name = "rules_jvm_external", version = "4.5")
maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")
这会将 use_extension 的返回值绑定到一个变量，以便用户使用点语法为扩展程序指定标记。这些标签必须遵循
由模板标签中指定的相应标记类定义的架构，
扩展程序定义。下面的示例展示了如何指定一些 maven.install 和 maven.artifact 标记：
maven.install(artifacts = ["org.junit:junit:4.13.2"])
maven.artifact(group = "com.google.guava",
artifact = "guava",
version = "27.0-jre",
exclusions = ["com.google.j2objc:j2objc-annotations"])
使用 use_repo 指令将扩展程序生成的代码库纳入当前模块的范围内。
use_repo(maven, "maven")
扩展程序生成的代码库属于其 API 的一部分。在此示例中，
“maven”模块扩展会承诺生成一个名为 maven 的代码库。使用上述声明后，该扩展程序会正确解析 @maven//:org_junit_junit 等标签，以指向“maven”扩展程序生成的代码库。
扩展定义
您可以定义模块扩展（类似于 Repo 规则），使用
module_extension 函数。不过，
虽然 repo 规则有多个属性，但模块扩展
tag_class，每个元素都含有
属性。代码类用于定义此扩展程序使用的代码的架构。对于
“maven”可以定义如下：
# @rules_jvm_external//:extensions.bzl
_install = tag_class(attrs = {"artifacts": attr.string_list(), ...})
_artifact = tag_class(attrs = {"group": attr.string(), "artifact": attr.string(), ...})
maven = module_extension(
implementation = _maven_impl,
tag_classes = {"install": _install, "artifact": _artifact},
)
这些声明表明，可以使用指定的属性架构指定 maven.install 和 maven.artifact 标记。
模块扩展的实现功能与 repo 的实现功能类似
但会获取一个 module_ctx 对象，
该权限可授予对使用该扩展程序和所有相关标记的所有模块的访问权限。
然后，实现函数会调用代码库规则来生成代码库。
# @rules_jvm_external//:extensions.bzl
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file") # a repo rule
def _maven_impl(ctx):
# This is a fake implementation for demonstration purposes only
# collect artifacts from across the dependency graph
artifacts = []
for mod in ctx.modules:
for install in mod.tags.install:
artifacts += install.artifacts
artifacts += [_to_artifact(artifact) for artifact in mod.tags.artifact]
# call out to the coursier CLI tool to resolve dependencies
output = ctx.execute(["coursier", "resolve", artifacts])
repo_attrs = _process_coursier_output(output)
# call repo rules to generate repos
for attrs in repo_attrs:
http_file(**attrs)
_generate_hub_repo(name = "maven", repo_attrs)
扩展程序身份
模块扩展由显示的名称和 .bzl 文件标识
在对 use_extension 的调用中。在以下示例中，扩展程序 maven 由 .bzl 文件 @rules_jvm_external//:extension.bzl 和名称 maven 标识：
maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")
从其他 .bzl 文件重新导出扩展程序会为其提供新的身份，如果传递模块图中使用了该扩展程序的两个版本，则系统会分别对它们进行评估，并且只会看到与该特定身份相关联的标记。
作为扩展程序作者，您应确保用户只能使用来自单个 .bzl 文件的模块扩展程序。
代码库名称和可见性
扩展程序生成的代码库采用 module_repo_canonical_name~extension_name~repo_name 格式的规范名称。对于托管在
根模块，module_repo_canonical_name 部分是
替换为字符串_main。请注意，规范名称格式不是您应依赖的 API，它可能会随时发生变化。
此命名政策表示，每个扩展程序都有自己的“repo 命名空间”；二
不同的扩展程序可以分别定义具有相同名称的代码库，而不会存在风险
避免任何冲突这还意味着，repository_ctx.name 会报告规范名称
代码库的名称，该名称不同于代码库规则中指定的名称
调用。
考虑到由模块扩展生成的代码库，有几个代码库公开范围规则：
- Bazel 模块代码库可以查看其
MODULE.bazel文件中引入的所有代码库 通过bazel_dep和use_repo。 - 由模块扩展程序生成的代码库可以看到托管该扩展程序的模块可见的所有代码库，以及由同一模块扩展程序生成的所有其他代码库（使用代码库规则调用中指定的名称作为其显式名称）。
- 这可能会导致冲突。如果模块代码库可以看到包含以下内容的代码库：
表观名称
foo，并且该扩展程序会生成一个包含 指定名称foo，则针对该扩展程序生成的所有代码库foo是指前者。
- 这可能会导致冲突。如果模块代码库可以看到包含以下内容的代码库：
表观名称
最佳做法
本部分介绍了编写扩展程序的最佳实践，以便扩展程序易于使用、可维护且能够适应随时间推移而发生的变化。
将每个扩展名放在单独的文件中
当扩展程序位于不同的文件中时，一个扩展程序可以加载另一个扩展程序生成的代码库。即使您不使用 所以最好将它们放在单独的文件中，以备不时之需 。这是因为扩展程序的标识基于其文件，因此日后将扩展程序移至其他文件会更改您的公共 API，并且对用户而言是向后不兼容的更改。
指定操作系统和架构
如果您的扩展程序依赖于操作系统或其架构类型，
请务必使用 os_dependent 在扩展定义中指明这一点
和 arch_dependent 布尔值属性。这样可以确保，如果其中任一项发生变化，Bazel 会认识到需要重新评估。
只有根模块会直接影响代码库名称
请注意，当扩展程序创建代码库时
扩展的命名空间也就是说，如果不同
模块使用相同的扩展程序，并最终创建具有相同
名称。这通常表现为模块扩展程序的 tag_class 具有 name
作为代码库规则的 name 值传递的参数。
例如，假设根模块 A 依赖于模块 B。两个模块
依赖于模块 mylang。如果 A 和 B 都调用 mylang.toolchain(name="foo")，它们都会尝试在 mylang 模块中创建名为 foo 的代码库，并且会发生错误。
为避免这种情况，请移除直接设置代码库名称的功能，或者仅允许根模块执行此操作。允许根模块执行此操作是可以的，因为没有任何内容会依赖于它，因此它不必担心其他模块会创建冲突的名称。