【Zig 日报】两项包管理（zig build）工作流改进

[jiacai2050]

作者：Andrew Kelley

如果你有一个包含依赖项的 Zig 项目，最近有两项重大变更刚刚上线，我想你一定会感兴趣。

1. 依赖包本地化存储

获取的依赖包现在将存储在项目根目录的 zig-pkg 目录下（与你的 build.zig 文件同级）。

例如，以下是在 awebo 项目中运行 zig build 后的一些结果：

$ du -sh zig-pkg/*
13M    freetype-2.14.1-alzUkTyBqgBwke4Jsot997WYSpl207Ij9oO-2QOvGrOi
20K    opus-0.0.2-vuF-cMAkAADVsm707MYCtPmqmRs0gzg84Sz0qGbb5E3w
4.3M   pulseaudio-16.1.1-9-mk_62MZkNwBaFwiZ7ZVrYRIf_3dTqqJR5PbMRCJzSuLw
5.2M   uucode-0.1.0-ZZjBPvtWUACf5dqD_f9I37VGFsN24436CuceC5pTJ25n
728K   vaxis-0.5.1-BWNV_AxECQCj3p4Hcv4U3Yo1WMUJ7Z2FUj0UkpuJGxQQ

强烈建议将此目录添加到项目的源码控制忽略文件（如 .gitignore）中。然而，通过将其置于 .zig-cache 之外，它提供了分发“自包含源码包”的可能性——这种包包含了所有依赖项，因此可用于离线构建或归档。

同时，依赖项的副本也会在全局进行缓存。在根据路径过滤器（paths filter）过滤掉所有未使用文件后，内容会被重新压缩：

$ du -sh ~/.cache/zig/p/*
2.4M    freetype-2.14.1-alzUkTyBqgBwke4Jsot997WYSpl207Ij9oO-2QOvGrOi.tar.gz
4.0K    opus-0.0.2-vuF-cMAkAADVsm707MYCtPmqmRs0gzg84Sz0qGbb5E3w.tar.gz
636K    pulseaudio-16.1.1-9-mk_62MZkNwBaFwiZ7ZVrYRIf_3dTqqJR5PbMRCJzSuLw.tar.gz
880K    uucode-0.1.0-ZZjBPvtWUACf5dqD_f9I37VGFsN24436CuceC5pTJ25n.tar.gz
120K    vaxis-0.5.1-BWNV_BFECQBbXeTeFd48uTJRjD5a-KD6kPuKanzzVB01.tar.gz

这一变化的动力是为了让“折腾”变得更容易。尽管去修改这些文件，看看会发生什么；把包目录替换成 git clone 的仓库；统一对所有依赖项进行 Grep 搜索；配置 IDE 基于 zig-pkg 目录进行自动补全；或者在你的依赖树上运行磁盘空间分析工具（如 baobab）。

此外，让全局缓存存储压缩文件可以更方便地在计算机之间共享缓存数据。未来，我们计划支持依赖树的 P2P 种子下载。通过将软件包重新压缩为规范格式，这将允许节点以最小带宽共享 Zig 软件包。我非常喜欢这个主意，因为它既能提供应对网络故障的韧性，又像是一场“人气竞赛”——通过做种者的数量就能看出哪些开源包最受欢迎！

2. 新增 --fork 命令行标志

第二个改进是在 zig build 中增加了 --fork 标志。

回想起来，这似乎显而易见，我不知道为什么从一开始没考虑到它。它的用法如下：

zig build --fork=[路径]

这是一个项目覆盖选项。通过提供一个本地源码检出路径，整个依赖树中所有匹配该项目的包都将被覆盖。

得益于包内容哈希（Package Content Hashes）包含了名称和指纹信息，这种覆盖在尝试获取包之前就能生效。

这是一种临时使用位于完全独立目录中的 Fork 版本的简便方法。你可以对整个依赖树进行迭代，直到一切正常工作，同时可以自如地使用依赖项目的开发环境和版本控制系统。

由于它是一个 CLI 标志，这使得它具有恰到好处的“临时性”。一旦去掉该标志，你就会立刻回到使用原始的、自动获取的依赖树状态。

如果项目不匹配，会报错以防止混淆：

$ zig build --fork=/home/andy/dev/mime
error: fork /home/andy/dev/mime matched no mime packages

如果项目匹配，你会收到正在使用 Fork 的提示：

$ zig build --fork=/home/andy/dev/dvui
info: fork /home/andy/dev/dvui matched 1 (dvui) packages
...

此功能旨在增强处理生态系统变动导致构建损坏（breakage）时的流转效率。我已经尝试了一段时间，发现它的工作体验非常愉快。新的工作流如下：

1. 因生态系统变动导致源码构建失败。
2. 使用 --fork 进行修补，直到项目恢复工作。在此期间，你可以使用上游的实际源码控制、测试套件、zig build test --watch -fincremental 等。
3. 现在你有了新选择：要么“自私”一点，继续忙你自己的事；要么将你的补丁提交给上游。

……而且你大概可以跳过将 build.zig.zon 指向你的 Fork 这一步，除非你预料到上游需要很长时间才能合并你的修复。

https://ziglang.org/devlog/2026/#2026-02-06

加入我们

Zig 中文社区是一个开放的组织，我们致力于推广 Zig 在中文群体中的使用，有多种方式可以参与进来：

1. 供稿，分享自己使用 Zig 的心得
2. 改进 ZigCC 组织下的开源项目
3. 加入微信群、Telegram 群组