Nix Flakes and their Guix Equivalents

查看原文 / View Original 编辑 / Edit

Nix Flakes and their Guix Equivalents

Nix Flakes 及其 Guix 等价物

I want to tell you a secret that took me WAY too long to internalize: there is no such thing as “the Guix equivalent of a flake.” I KNOW!! That sounds like a cop-out!! But stick with me — it’s actually the most interesting thing about this entire comparison. Flakes are one big feature that solves a bunch of problems at once (Dolstra, 2020). Guix solves those same problems, but it does so with a collection of smaller, orthogonal tools that were mostly in place before flakes even existed (Contributors, 2025a). So the mapping isn’t flake → ??? — it’s flake → channels, and manifests, and guix describe, and guix shell, and operating-system declarations, and… Okay I’m getting ahead of myself. Let me set the stage first.

我想告诉大家一个我花了太久时间才领悟的秘密：根本不存在所谓的“Guix 版 Flake”。我知道！！这听起来像是在推卸责任！！但请听我说——这实际上是整个对比中最有趣的部分。Flakes 是一个庞大的功能，旨在一次性解决一系列问题 (Dolstra, 2020)。Guix 解决了同样的问题，但它使用的是一系列更小、更正交的工具，这些工具在 Flakes 出现之前就已经基本就位了 (Contributors, 2025a)。因此，映射关系不是 Flake → ???，而是 Flake → channels、manifests、guix describe、guix shell、operating-system declarations 等等……好吧，我有点操之过急了。先让我铺垫一下。

1. Who is this for?

1. 这篇文章是写给谁看的？

If you’re a Nix person, you probably know Guix as “that other functional package manager, the one that uses Scheme.” You might have heard it described as a Nix fork — and there is shared lineage! Guix reused the Nix daemon (the C++ component that handles build isolation and store management) and builds everything else from scratch in Guile Scheme ((rekado), 2019). The derivation format (ATerm) is shared (Khana, 2026), the daemon lineage is shared, but the language, the package definitions, the service system, the whole world above the daemon — that’s all Guix’s own thing ((rekado), 2020).

如果你是 Nix 用户，你可能知道 Guix 是“那个使用 Scheme 的函数式包管理器”。你可能听说过它是 Nix 的一个分支——它们确实有共同的血统！Guix 重用了 Nix 守护进程（负责构建隔离和存储管理的 C++ 组件），并用 Guile Scheme 从零开始构建了其他所有内容 ((rekado), 2019)。派生格式 (ATerm) 是共享的 (Khana, 2026)，守护进程的血统也是共享的，但语言、包定义、服务系统以及守护进程之上的整个世界——那都是 Guix 自己的东西 ((rekado), 2020)。

If you’re a Guix person, you’ve probably seen Nix people talking about “flakes” and wondered what the big deal is. Maybe you’ve felt a tiny pang of — wait, do we not have that? Are we behind? The answer to both is: RELAX!! Guix has all of the capabilities that flakes provide. It just delivers them in a different shape. And understanding that shape is what this post is about.

如果你是 Guix 用户，你可能见过 Nix 用户讨论“Flakes”并好奇它到底有什么了不起。也许你曾感到一丝不安——等等，我们没有这个功能吗？我们落后了吗？这两个问题的答案都是：放轻松！！Guix 拥有 Flakes 所提供的所有功能，只是它以不同的形式呈现出来。而理解这种形式正是本文的目的。

2. What even is a flake, anyway?

2. 到底什么是 Flake？

A brief primer for the Guix folks in the room!! (Nix people, you can skim this — or maybe read it anyway, sometimes the refresher is nice :3) A Nix flake is, at its core, just a source tree — typically a Git repository — that contains a file called flake.nix in its root. That’s it. The presence of flake.nix is what makes it a flake (Project, 2024).

为在场的 Guix 用户做一个简短的入门介绍！！（Nix 用户可以略读，或者读一读也行，温故而知新嘛 :3）Nix Flake 本质上就是一个源代码树——通常是一个 Git 仓库——其根目录下包含一个名为 flake.nix 的文件。仅此而已。flake.nix 的存在使其成为一个 Flake (Project, 2024)。

(… content truncated for brevity …)

When you run any nix command against a flake, Nix also generates a flake.lock — a JSON file that pins every input and their inputs, transitively, to exact revisions. This lock file is what makes builds reproducible across machines and across time. Flakes also enforce pure evaluation: no $NIX_PATH, no builtins.currentSystem, no environment variables leaking in. Everything must be explicit (Contributors, 2026).

当你对一个 Flake 运行任何 nix 命令时，Nix 还会生成一个 flake.lock——这是一个 JSON 文件，它将每个输入及其传递依赖项锁定到确切的版本。正是这个锁文件使得构建能够在不同机器和不同时间保持可复现性。Flakes 还强制执行纯评估：没有 $NIX_PATH，没有 builtins.currentSystem，也没有环境变量泄露。一切都必须是显式的 (Contributors, 2026)。

So, to summarize, flakes do roughly six things:

  1. Declare dependencies (inputs)
  2. Pin dependencies (flake.lock)
  3. Enforce purity (no implicit state)
  4. Provide a standard output schema (packages, devShells, apps, nixosConfigurations, etc.)
  5. Enable reproducible sharing (anyone can nix build github:you/your-repo)
  6. Define development environments (devShells)

总之，Flakes 大致做了六件事：

  1. 声明依赖 (inputs)
  2. 锁定依赖 (flake.lock)
  3. 强制纯净 (无隐式状态)
  4. 提供标准输出模式 (packages, devShells, apps, nixosConfigurations 等)
  5. 实现可复现的共享 (任何人都可以 nix build github:you/your-repo)
  6. 定义开发环境 (devShells)

Now here’s the key insight: Guix already had solutions for most of these before flakes were introduced in Nix 2.4 on November 1, 2021 (Project, 2021). The channels mechanism landed in Guix around 2018–2019 (Contributors, 2025a). And the solutions are orthogonal — you can use each one independently, without buying into a single monolithic abstraction. Let’s go through them one by one!! This is the fun part!!

现在关键的见解来了：在 2021 年 11 月 1 日 Nix 2.4 引入 Flakes 之前，Guix 就已经有了解决其中大多数问题的方案 (Project, 2021)。Channels 机制大约在 2018-2019 年进入 Guix (Contributors, 2025a)。而且这些解决方案是正交的——你可以独立使用每一个，而无需接受单一的整体抽象。让我们逐一来看！！这才是最有趣的部分！！

← 返回新闻列表 / Back to news list