Bazel 通过从 Bazel 注册表（Bazel 模块的数据库）请求依赖项的信息来发现依赖项。Bazel 仅支持一种类型的注册表，即索引注册表，它们是遵循特定格式的本地目录或静态 HTTP 服务器。
索引注册表
索引注册表是一个本地目录或静态 HTTP 服务器，其中包含有关模块列表的信息，包括模块的首页、维护者、每个版本的 MODULE.bazel 文件，以及如何获取每个版本的源代码。值得注意的是，它不需要自行提供源归档文件。
索引注册表必须采用以下格式：
/bazel_registry.json：一个可选的 JSON 文件，包含注册表的元数据。/modules：一个目录，其中包含此注册表中每个模块的子目录/modules/$MODULE：一个目录，其中包含名为$MODULE的模块的每个版本的子目录，以及包含此模块元数据的metadata.json文件。/modules/$MODULE/$VERSION：包含以下文件的目录：MODULE.bazel：相应模块版本的MODULE.bazel文件。请注意，这是 Bazel 在解析外部依赖项期间读取的MODULE.bazel文件，而非源归档中的文件（除非存在非注册表替换）。另请注意，最好使用此文件来设置发布版本的版本，避免在源归档MODULE.bazel文件中进行此操作。如需详细了解模块版本控制，请参阅常见问题解答。source.json：一个 JSON 文件，其中包含有关如何获取相应模块版本来源的信息patches/：包含补丁文件的可选目录，仅在source.json具有“archive”类型时使用overlay/：包含叠加文件的可选目录，仅在source.json具有“archive”类型时使用
bazel_registry.json
bazel_registry.json 是一个可选文件，用于指定适用于整个注册表的元数据。它可以包含以下字段：
mirrors：一个字符串数组，用于指定要用于源归档的镜像列表。- 镜像网址是镜像本身与模块的源网址（由其
source.json文件指定，不含协议）的串联。例如，如果模块的源网址为https://foo.com/bar/baz，且mirrors包含["https://mirror1.com/", "https://example.com/mirror2/"]，则 Bazel 将按顺序尝试的网址为https://mirror1.com/foo.com/bar/baz、https://example.com/mirror2/foo.com/bar/baz，最后是原始源网址本身https://foo.com/bar/baz。
- 镜像网址是镜像本身与模块的源网址（由其
module_base_path：一个字符串，用于指定source.json文件中具有local_path类型的模块的基本路径
metadata.json
metadata.json 是一个可选的 JSON 文件，其中包含有关模块的信息，具有以下字段：
versions：一个字符串数组，每个字符串都表示相应注册表中可用的模块版本。此数组应与模块目录的子项相匹配。yanked_versions：一个 JSON 对象，用于指定相应模块的已撤消版本。键应为要撤消的版本，值应为撤消相应版本的原因说明，最好包含指向更多信息的链接。
请注意，BCR 需要在 metadata.json 文件中提供更多信息。
source.json
source.json 是必需的 JSON 文件，其中包含有关如何提取模块特定版本的信息。此文件的架构取决于其 type 字段，该字段的默认值为 archive。
- 如果
type为archive（默认值），则此模块版本由http_archiverepo 规则提供支持；它通过从给定网址下载归档文件并提取其内容来获取。它支持以下字段：url：一个字符串，即源归档的网址mirror_urls：一个字符串列表，包含源归档的镜像网址。 在url之后，系统会按顺序尝试这些网址作为备份。integrity：一个字符串，表示归档文件的子资源完整性校验和strip_prefix：一个字符串，用于在提取源归档时剥离目录前缀overlay：一个 JSON 对象，其中包含要叠加在提取的归档文件之上的叠加文件。补丁文件位于/modules/$MODULE/$VERSION/overlay目录下。键是叠加层文件名，值是叠加层文件的完整性校验和。覆盖层在补丁文件之前应用。patches：一个 JSON 对象，包含要应用于提取的归档文件的补丁文件。补丁文件位于/modules/$MODULE/$VERSION/patches目录下。键是补丁文件名，值是补丁文件的完整性校验和。补丁会在叠加文件之后应用，并按照它们在patches中的显示顺序应用。patch_strip：一个数字；与 Unixpatch的--strip实参相同。archive_type：一个字符串，表示下载文件的归档类型（与http_archive上的type相同）。
- 如果
type为git_repository，则此模块版本由git_repository代码库规则提供支持；它通过克隆 Git 代码库来获取。- 支持以下字段，这些字段会直接转发到基础
git_repositoryrepo 规则：remote、commit、shallow_since、tag、init_submodules、verbose和strip_prefix。
- 支持以下字段，这些字段会直接转发到基础
- 如果
type为local_path，则此模块版本由local_repository代码库规则提供支持；它会符号链接到本地磁盘上的某个目录。它支持以下字段：path：代码库的本地路径，计算方式如下：- 如果
path是绝对路径，则保持不变 - 如果
path是相对路径，而module_base_path是绝对路径，则解析为<module_base_path>/<path> - 如果
path和module_base_path都是相对路径，则解析为<registry_path>/<module_base_path>/<path>。 注册表必须在本地托管，并由--registry=file://<registry_path>使用。否则，Bazel 将抛出错误
- 如果
Bazel 中央注册表
位于 https://bcr.bazel.build/ 的 Bazel 中央注册中心 (BCR) 是一个索引注册中心，其内容由 GitHub 代码库 bazelbuild/bazel-central-registry 提供支持。您可以使用 https://registry.bazel.build/ 上的 Web 前端浏览其内容。
Bazel 社区负责维护 BCR，欢迎贡献者提交拉取请求。请参阅 BCR 贡献指南。
除了遵循常规索引注册表的格式之外，BCR 还要求每个模块版本 (/modules/$MODULE/$VERSION/presubmit.yml) 都有一个 presubmit.yml 文件。此文件指定了一些基本的 build 和测试目标，您可以使用这些目标来检查相应模块版本的有效性。BCR 的 CI 流水线也使用此功能来确保模块之间的互操作性。
选择注册表
可重复的 Bazel 标志 --registry 可用于指定要从中请求模块的注册表列表，因此您可以设置项目以从第三方或内部注册表中提取依赖项。较早的注册优先。为方便起见，您可以将 --registry 标志的列表放在项目的 .bazelrc 文件中。
如果您的注册表托管在 GitHub 上（例如，作为 bazelbuild/bazel-central-registry 的分支），则您的 --registry 值需要 raw.githubusercontent.com 下的原始 GitHub 地址。例如，在 my-org 分叉的 main 分支上，您需要设置 --registry=https://raw.githubusercontent.com/my-org/bazel-central-registry/main/。
使用 --registry 标志会阻止默认使用 Bazel 中央注册表，但您可以通过添加 --registry=https://bcr.bazel.build 将其重新添加回来。