nixpkgs 状况不佳

# nixpkgs 的情况不太妙 来源：https://foxgirl.engineering/blog/nixpkgs-not-hot/ 如果你之前没看出来（https://foxgirl.engineering/blog/core-services-part-1/）（https://foxgirl.engineering/blog/unattended-nixos-installer/），我算是个 Nix 爱好者。我总喜欢把它塞进一切合适的地方，也塞进大多数不合适的地方。我就是觉得它很精巧¹。能够以极其精确且稳定的方式指定 Linux 系统或开发环境的每一个方面，这种能力一旦尝到甜头，我就再也放不下了。NixOS 和 Nixpkgs 中编码了太多的知识，说实话，能有这么多人聚集起来并为之做出贡献，本身就有点不可思议。这是一个庞大的社区工程，是那种很少出现、但一旦出现就真的挺美好的东西，你懂吗？ ……等等。*嗅嗅* 等一下。*再嗅嗅* 你闻到了吗？闻起来像……像维护者。 *烧焦的* 维护者。 哦不。 ## 我们无法从上面越过 更广泛的 Nix 项目（也就是 Nix/NixOS/Nixpkgs 三位一体）在相当长一段时间里，一直，呃……深陷于（https://web.archive.org/web/20240506193540/https://nixos-users-against-mic-sponsorship.github.io/）治理（https://web.archive.org/web/20250330225612/https://save-nix-together.org/）的复杂性（https://discourse.nixos.org/t/the-sc-prepared-to-lie-to-us-and-what-we-can-do-about-it-whistleblow/70103）之中，可以这么说。从“事实上的 BDFL”到“结构化治理机构/团队”的过渡在开始时相当艰难，但总体形态似乎已经基本稳定下来了。我没有特别密切关注这个新结构的进展如何，²（https://foxgirl.engineering/blog/nixpkgs-not-hot/#fn.2）但根据我所看到的，结果好坏参半。有一些棘手的地方，但也有一些迹象表明项目的某些部分正在朝着积极的方向发展，这还是很值得高兴的。 不幸的是，这些结构最近似乎不太顺利。最近，Nixpkgs 核心团队宣布解散（https://discourse.nixos.org/t/the-nixpkgs-core-team-has-disbanded/79413），理由是成员流失问题以及指导委员会（Steering Committee）效率低下。这个团队发现自己陷入了只能选择解散的境地，这确实令人遗憾，但我也忍不住想知道，这个结果是否在某种程度上是不可避免的。Nix 组织中似乎正在出现一种模式：组建团队来处理项目管理的某些方面，然后在努力进行有效管理却遇到困难后解散。³（https://foxgirl.engineering/blog/nixpkgs-not-hot/#fn.3） 虽然指导委员会在這些事件中反复出现，但我不确定是否能把所有责任都归咎于他们。在我看来，这里有一个更根本的问题，那就是倦怠。志愿者团队聚集在一起，试图为 Nix 项目提供指导，但最终却以失败告终，因为这些志愿者开始意识到自己已经没有剩余的能力来提供这种指导，于是选择离开他们的团队。我真的不能责怪他们——尤其是 Nixpkgs，它是一个绝对*庞大*的项目。即使不把一个效果存疑的指导委员会加进来，光是 NixOS、应用打包、语言特定工具、CI 和发布管理等等方面，就有太多东西需要管理、设计和委派了……对于一群志愿者组成的社区来说，这要求太高了。仅靠更好的治理无法解决这个根本性的规模问题。 ## 我们无法从下面穿过 每当有人批评项目领导层时，总有一群人带着那句老掉牙的话出现：“直接 fork 项目啊 4Head”⁴（https://foxgirl.engineering/blog/nixpkgs-not-hot/#fn.4）。这种话很少是真心实意说的，但好吧。行。咱们姑且认真考虑一下这个想法。更广泛的 Nix 项目确实存在治理方面的问题，理论上我们可以通过把项目带出那个治理环境来绕过这些问题。那样会奏效吗？ 事实证明，去年确实有人尝试过这样做，那就是命运多舛的 Floral 项目。那是一个非常雄心勃勃的项目，试图完全 fork 一份 Nixpkgs，并配备所有必要的支持基础设施。先不深入细节，⁵（https://foxgirl.engineering/blog/nixpkgs-not-hot/#fn.5）这个项目一开始势头很猛，但随着任务的真正规模逐渐清晰，以及我们发现自己缺乏时间和专业技能来构建运行 Nixpkgs fork 所需的工具，项目就逐渐衰落了。 维护和提供 Nixpkgs 所需的工作远比表面上看起来复杂得多。需要特别指出的是，其中一个组成部分是一个 CI 系统，它需要能够构建绝大部分 Nixpkgs 包集合——这是最大（如果不是最大的话）的软件包定义集合之一——并且要同时支持 Linux 和 Darwin，还要覆盖多种架构。这可不是小事！这和“小事”恰恰相反！没有这个非常复杂的 CI 系统，你就不可能拥有 Nixpkgs，否则你就有向下游用户提供损坏包的风险。 我看到有些人把 Nixpkgs 描述为“大到无法 fork”，确实，我同意这个看法。事实上，我甚至想更进一步说，Nixpkgs 可能已经大到无法*维护*了。如果一个志愿者群体发现自己因为其巨大规模而无法接手并运营这个项目，那么主项目的志愿者群体也会感到倦怠，这就不足为奇了。这是一个必然复杂的项目，你不能仅仅通过 fork 就摆脱这种复杂性，除非大幅缩减其范围。 ## 但到底该怎么穿过它 显然，现在的情况已经变得相当难以为继了。Nixpkgs 没能通过治理来摆脱倦怠，更广泛的社区似乎也无法通过 fork 来摆脱困境。我们该何去何从？需要发生什么才能让 Nixpkgs 进入一个能够蓬勃发展的状态，让领导层不必被困在那些让他们失望的体系里，也不必依赖少数几个懂其全部技术复杂性的志愿者的努力？ 也许是时候开始缩减范围了。Nixpkgs 如此全面，确实令人惊叹，但——说实话——没有人会用到*所有* Nixpkgs 的内容。把所有东西都打包进去是一个令人钦佩的目标，但这个目标真的开始让项目付出代价了。有选择地决定什么可以被接纳入 Nixpkgs，可能会大大减轻维护者的负担。当然，把所有东西都放在 Nixpkgs 里很方便，但通过像 npins（https://github.com/andir/npins）和 Flakes 这样的工具和特性，引入定义在其他地方的包也并不难。我认为在这方面，Tidepool（https://git.auxolotl.org/auxolotl/labs/src/branch/main/tidepool）中还有一些有趣的技术想法，这是 Auxolotl 项目（https://auxolotl.org/en/）从头创建 Nix 包集合的尝试。 资金能否成为解决方案的一部分？我知道，我自己有些项目，如果不是有报酬的话，我真的很不愿意去维护。说到底，我们都只是普通人⁶（https://foxgirl.engineering/blog/nixpkgs-not-hot/#fn.6）——志愿工作固然值得敬佩，但我们还是得保住那些能付账单、养家糊口的工作。如今有很多关于“开源危机”的讨论，尤其是 LLM 编码工具降低了门槛，让那些最令人无法忍受的科技男更容易破坏开源维护者的信噪比。开源维护者一直在承担大量无偿工作，而随着推动开源模式的公司最后那一丝伪装逐渐脱落，这些工作的现实正在迅速反噬到他们身上。 归根结底，我只是世界上的一只小狐狸。我没有所有答案，尽管我很喜欢在自己脑子里琢磨答案可能是什么。我可能也没有看到全貌，因为我在 Nix 项目治理相关空间里花的时间太少了。但是，作为一个长期的 Nix 用户，我忍不住要为这个项目的未来担忧。这种情况已经持续相当长一段时间了，而这一切很糟糕。看到参与这个了不起项目的每个人都被耗尽精力然后离开，真的很糟糕。我真希望能在文章结尾留下一些积极的话，但我现在剩下的只有更多的问题，而不是答案。不过，我想这正是我在博客上写这篇文章的原因——让越多的人来思考这些问题，我们就越有可能找到答案。 ## 脚注