NUR：绕过 Nixpkgs 审核的社区包仓库，便利与风险并存

Nixpkgs 太慢，NUR 想走另一条路

Nixpkgs 是 Nix 生态的官方包集合，但它有严格的审核流程。一个新包从提交到合并，可能需要数周甚至数月。NUR 的定位就是绕过这个流程。它是一个元仓库，本身不直接包含包，而是收集用户各自维护的仓库，每个仓库提供一个 default.nix，里面定义了一组 Nix 表达式。用户可以通过 nur.repos.<用户名>.<包名> 这样的属性路径来引用这些包。核心区别在于，NUR 明确声明这些包没有经过任何 Nixpkgs 成员的审核。它解决的是速度问题，代价是安全审查的缺失。

属性路径背后的机制：从仓库到可安装包

NUR 的工作方式可以拆成三步。第一步，贡献者创建一个包含 default.nix 的仓库，注册到 NUR 的列表。第二步，NUR 自动检查这个列表，对每个仓库执行评估检查，确保表达式能被 Nix 正确解析。第三步，NUR 将所有这些仓库的表达式合并到一个 nur-combined 仓库中，方便统一搜索。当你在配置中写 nur.repos.mic92.hello-nur 时，Nix 会从 NUR 的集合中取出 mic92 这个仓库的表达式，再从中取出 hello-nur 这个属性。整个流程是去中心化的，每个贡献者对自己的仓库内容负责。但注意，评估检查只验证语法和依赖是否可解析，不检查代码是否安全。

安装 NUR：三种方式，各有取舍

README 给出了三种安装方式。第一种是用 flake，在 flake.nix 的 inputs 中加入 nur，并设置 inputs.nixpkgs.follows = "nixpkgs"，然后通过 overlays.default 或 legacyPackages 使用。第二种是用 packageOverrides，在 ~/.config/nixpkgs/config.nix 中写 packageOverrides = pkgs: { nur = import (builtins.fetchTarball "...") { inherit pkgs; }; }。第三种是 NixOS 系统级，在 configuration.nix 中设置 nixpkgs.config.packageOverrides。对于非 flake 方式，README 特别提醒，如果要在 nix-env、home-manager 或 nix-shell 中使用 NUR，也必须把这个配置加到 ~/.config/nixpkgs/config.nix。

固定版本：避免一小时的缓存陷阱

README 提到了一个实际的问题：使用 builtins.fetchTarball 而不指定 sha256 时，下载只会缓存 1 小时。这意味着每次构建都可能需要重新访问网络，在离线或网络不稳定的环境下会频繁失败。解决办法是固定版本，先选择一个 commit 的 tarball URL，然后用 nix-prefetch-url --unpack 获取哈希，再把 url 和 sha256 都写进 fetchTarball。这个操作虽然多两步，但能保证构建的可复现性。对于生产环境，这是必须的步骤，否则你的系统配置会变得不可预测。

在 NixOS 和 Home Manager 中集成 NUR 模块

NUR 不仅提供包，还允许用户贡献 NixOS 模块和 Home Manager 模块。在 NixOS 配置中，你可以通过 nur.modules.nixos.default 添加 overlay，然后直接导入 nur.repos.iopq.modules.nixos.xraya 这样的模块。Home Manager 的集成类似，通过 imports = lib.attrValues nur.repos.moredhel.modules.homeManager 来导入所有模块。对于独立运行的 Home Manager 配置，需要把 NUR overlay 和所需模块加到 homeManagerConfiguration 的 modules 列表中。这种设计让 NUR 不只是包仓库，还是一个模块分发渠道。

安全风险：没有审核的默认状态

README 用加粗字体明确警告：NUR 不会定期检查仓库中的恶意内容，建议在安装前检查表达式。这是 NUR 最核心的局限。与 Nixpkgs 不同，NUR 的包没有经过任何安全审查，任何用户都可以注册一个仓库，放入看似正常的包，但实际上可能包含恶意代码。NUR 的评估检查只能发现语法错误，无法检测逻辑漏洞。对于企业环境或对安全敏感的用户，这是一个严重的风险。如果你安装了一个来自陌生人的包，你实际上是在执行他写的 Nix 表达式，这等同于运行任意代码。

与 Nixpkgs 的对比：速度 vs 信任

Nixpkgs 和 NUR 的差别不在于技术，而在于信任模型。Nixpkgs 有明确的审核流程，包在被合并前会经过多个维护者的检查，因此可以被视为相对可信的来源。NUR 则完全依赖贡献者的自觉，没有中间审查层。这意味着 NUR 的包更新速度更快，但质量参差不齐。如果你需要的是一个已经被广泛使用的包，比如 hello-nur 这样的测试包，NUR 没问题。但如果你需要的是生产环境用的数据库驱动或安全工具，Nixpkgs 的审核流程会更合适。NUR 适合作为 Nixpkgs 的补充，而不是替代品。

维护成本与许可证

NUR 本身使用 MIT 许可证，这意味着你可以自由使用和修改它的代码。但每个用户仓库可能使用不同的许可证，你需要单独检查。维护方面，NUR 的自动评估检查可以减少一些手工工作，但贡献者需要确保自己的 default.nix 能通过检查。如果你使用非固定的 fetchTarball，每次构建都可能拉取最新版本，这会导致配置漂移，增加维护成本。建议总是固定版本。此外，NUR 的仓库列表由社区维护，如果你依赖的某个仓库被删除或停止更新，你的配置就会失效。

编辑结论

如果你是一个 Nix 用户，需要快速获取尚未进入 Nixpkgs 的新包，或者想分享自己的包而不想等待审核，NUR 是一个可行的选择。但你应该只用它来安装你信任的、或者已经仔细阅读过表达式的包。不要把它当作 Nixpkgs 的替代品，它没有审核机制，也不保证安全性。在使用前，先检查目标仓库的 default.nix 内容，确认没有恶意代码。如果你对安全性要求极高，或者只使用稳定且经过审核的包，那么请继续使用 Nixpkgs，不要引入 NUR。对于维护者，NUR 的评估检查只能发现语法错误，不能发现逻辑漏洞，所以发布前请自行测试。

官方来源

1. Official documentation
2. Official README
3. Project repository