bazel - `load` 的顺序是 Bazel 规范中的还是仅仅因为实现？

Question

我遇到了 a problem在使用 Bazel 构建 Go 项目时发现根本原因是 load 导入 @io_bazel_rules_go 的顺序。

收到答案后，我引用了 Bazel 的官方文档，如果它是在规范中定义的，或者只是对实现的隐式依赖。我还不能检查所有官方文档，但听起来以下文档与这个问题相关，而且 load 的顺序如何影响构建仍然很模糊；在我所经历的情况下，似乎较早的声明胜过较晚的声明。

• https://docs.bazel.build/versions/2.2.0/build-ref.html#load
• https://docs.bazel.build/versions/2.2.0/external.html#shadowing-dependencies

谁能澄清这是否符合规范？

Answer 1

有关覆盖外部存储库的文档含糊不清，但是 https://docs.bazel.build/versions/2.2.0/external.html可能是最好的引用。

我的理解是:

• 在 WORKSPACE 中或在 WORKSPACE 调用的函数中声明的存储库是延迟计算的。这很重要，因为评估存储库规则可能非常昂贵(它们往往会下载大文件)并且对于很多构建来说可能不是必需的。
• 以相同的名称多次声明存储库不是错误。如果尚未评估存储库规则，将使用最后的声明。
• 当存储库中的任何标签被解析时，存储库规则被评估。这包括:
  • 使用 load 语句加载 .bzl 文件。
  • 将属性中的标签传递给另一个被评估的存储库规则。
  • 在评估的另一个存储库规则中的标签上使用 ctx.path。
  • (在 WORKSPACE 完全解析后)构建一个加载某些内容或依赖于存储库中某些内容的目标。
• 在评估存储库规则后，它不能再被覆盖。稍后声明的同名存储库将被忽略。

这种逻辑很困惑，当多次声明规则时，很难理解使用的是什么版本。

• 理想情况下，每个规则都应该在 WORKSPACE 中声明一次，以尽量减少混淆。当然，如果您的依赖项提供声明传递依赖项的函数，那可能会很困难。在某些情况下，您最终可能会手动内联这些函数。
• 像 go_rules_dependencies 这样的依赖函数应该避免覆盖任何使用 _maybe 函数声明的东西，如下所示:

def _maybe(repo_rule, name, **kwargs):
    if name not in native.existing_rules():
        repo_rule(name = name, **kwargs)

• 安排您的 WORKSPACE 文件以确保直接依赖项得到声明并可能更早地解决。这可能会使相关声明的分组变得更加困难，但求值语义会更加清晰。
  • http_archive 和 git_repository 规则集和直接依赖项的存储库。
  • load 存储库规则和依赖函数的语句。
  • 其他直接依赖项(例如，go_repository)。
  • 为传递依赖调用依赖函数。
  • 工具链注册。

对于调试，native.existing_rules功能可以很方便。它返回到目前为止声明的所有存储库的列表，以及它们声明的属性。定义调用它并打印结果的函数，然后从 WORKSPACE 中的任何位置调用该函数。