如何在不使用相对路径的情况下从另一个规则访问bazel规则的输出？

Question

我试图使用Bazel编译一个基于dhall-kubernetes的dhall程序来生成一个Kubernetes YAML文件。

不使用dhall-kubernetes的基本dhall编译使用一个简单的bazel宏可以正常工作。

../../external/dhall-kubernetes/1.17/Prelude.dhall 

workspace(name = "dhall")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

DHALL_KUBERNETES_VERSION = "4.0.0"

http_archive(
    name = "dhall-kubernetes",
    sha256 = "0bc2b5d2735ca60ae26d388640a4790bd945abf326da52f7f28a66159e56220d",
    url = "https://github.com/dhall-lang/dhall-kubernetes/archive/v%s.zip" % DHALL_KUBERNETES_VERSION,
    strip_prefix = "dhall-kubernetes-4.0.0",
    build_file = "@//:BUILD.dhall-kubernetes",
)

构建。dhall-Kubernetes：

package(default_visibility=['//visibility:public'])

filegroup(
    name = "dhall-k8s-1.17",
    srcs = glob([
        "1.17/**/*",
    ]),
)

示例/K8S/Build:

package(default_visibility = ["//visibility:public"])

genrule(
    name = "special_ingress",
    srcs = ["ingress.dhall",
            "Prelude.dhall",
            "package.dhall",
        "@dhall-kubernetes//:dhall-k8s-1.17"
    ],
    outs = ["ingress.yaml"],
    cmd = "dhall-to-yaml --file $(location ingress.dhall) > $@",
    visibility = [
        "//visibility:public"
    ]
)

Answer 1

有一种方法可以对Dhall进行“脱机”构建，这意味着包管理器获取所有Dhall依赖项，而不是Dhall获取它们。

事实上，我为Nixpkgs实现了这样的内容，您可以将其翻译成Bazel：

• 添加对dhall的Nixpkgs支持

基本技巧是利用Dhall导入系统的一个特性，即如果缓存了一个受语义完整性检查（即“语义散列”）保护的包，那么Dhall将使用缓存而不是获取包。您可以在此技巧的基础上构建包管理器，通过以这种方式注入依赖项来绕过DHall的远程导入。

您可以在这里找到与NIX相关的逻辑：

• nix函数，用于构建Dhall包

...但我将尝试以包管理器独立的方式解释它是如何工作的。

首先，使用Nix构建的Dhall“包”的最终产品是一个具有以下结构的目录：

$ nix-build --attr 'dhallPackages.Prelude'         
…

$ tree -a ./result
./result
├── .cache
│   └── dhall
│       └── 122026b0ef498663d269e4dc6a82b0ee289ec565d683ef4c00d0ebdd25333a5a3c98
└── binary.dhall

2 directories, 2 files

该目录的内容是：

>

./cache/dhall/1220 xxx…xxx

包含单个构建产品的有效Dhall缓存目录：解释的Dhall表达式的二进制编码。

该文件被称为binary.Dhall，因为这是“二进制”包分发版的Dhall等效版本，这意味着导入只能从二进制缓存中获得，不能从源代码中获取和解释。

可选:./source.dhall

这是一个包含完全αβ规范化表达式的文件，该表达式等效于缓存的表达式。默认情况下，除了顶级包之外，所有包都应该省略这一点，因为它包含存储在./cache/1220xxx…xxx中的相同表达式，尽管效率较低（因为二进制编码更紧凑）

这个文件被称为./source.Dhall，因为这是“源”包分发版的Dhall等价物，它包含产生相同结果的有效源代码。

>

包名称

这对建筑来说并不重要。它只是命名事物，因为每个Nix包都必须有一个人类可读的名称。

生成的依赖项

此标志编译出对HTTP远程导入的支持，这样，如果用户忘记为远程导入提供依赖项，他们将得到一条错误消息，说导入解析被禁用

我们将在所有后续步骤中使用此可执行文件

在当前工作目录中创建名为.cache/dhall的缓存目录

...并用存储在每个依赖项的中的二进制文件填充缓存目录。/cache/目录

配置解释器以使用我们创建的缓存目录

...通过将xdg_cache_home设置为指向我们刚刚在当前工作目录中创建的.cache目录

...使用dhall encode命令，并将文件保存到$out/cache/dhall/1220${HASH}

创建./binary.dhall文件

...只需向$out/binary.dhall写入一个文本文件，其中包含缺少SHA256:${HASH}

可选：删除./source.dhall文件

...如果用户没有请求保留文件。默认情况下省略此文件有助于节省包存储区中的空间，因为不会两次存储相同的表达式（作为二进制文件和源代码）。

一旦你有了这个函数，有几个约定可以帮助简化“大体上”的事情。

>

默认情况下，包应生成项目的./package.dhall文件

使重写包版本变得容易

使重写包内构建的文件变得容易

换句话说，如果用户更喜欢导入像https://prelude.dhall-lang.org/list/map这样的单个文件，而不是顶级的./package.dhall文件，那么应该有一种方法让他们指定像prelude.override{file=“./list/map”；}这样的依赖项，以获得构建和缓存该单个文件的包。

我希望这能帮上忙！如果你有更多关于如何做到这一点的问题，你可以在这里问他们，或者你也可以在我们的话语论坛上讨论更多，尤其是在这个成语最初起源的线程上：

• Dhall语篇-前奏的脱机使用