Nixpkgs 互操作性标准深度解读CycloneDX SBOM 的 Nix 命名空间属性与 OpenXR 运行时兼容【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgsNixpkgs 手册中的「互操作性标准」章节定义了如何将 Nix 特有的信息store path、NAR 归档、fixed-output derivation 等以标准化方式嵌入外部互操作数据格式中使 Nix 产物能被主流软件物料清单SBOM工具与 XR 运行时识别与使用。本文将以该章节为骨架结合 Nixpkgs 仓库内 fetcher 的实际实现系统讲解 CycloneDX SBOM 中nix命名空间属性分类法nix:store_path、nix:narinfo、nix:fod与 OpenXR 运行时兼容指南帮助你在生成 SBOM 或接入 OpenXR 生态时正确表达 Nix 语义。1. 章节定位互操作标准在 Nixpkgs 手册中的角色在 Nixpkgs 文档树中doc/interoperability.md 是「Interoperability Standards」章节的入口文件它在 doc/nav.json 中挂载为手册的一级章节并包含两个子文档doc/interoperability/cyclonedx.md定义 CycloneDX SBOM 中用于承载 Nix 专有信息的属性命名空间doc/interoperability/openxr.md说明 NixOS 中 OpenXR 运行时提供者的共享库加载兼容要求。这两份文档的共同出发点是让 Nix/Nixpkgs 生态产出的构件store 中的组件、二进制缓存归档、派生产物能以可被外部工具解析的形式进入通用的互操作数据格式而不是停留在 Nix 内部闭包图里自成一派。2. CycloneDX 与「nix 命名空间属性分类法」CycloneDX 是由 OWASP 主导的软件物料清单SBOM标准用于记录软件组件、依赖、许可证、漏洞信息等。要让一份 SBOM 同时被 Nix 生态与外部 SBOM 工具理解就需要一套既遵循 CycloneDX 通用结构、又保留 Nix 专有语义的约定——这就是nix命名空间属性分类法nixNamespace Property Taxonomy。分类法建立在 CycloneDX 的 properties组件属性机制之上其基础规则是组件属性是「名-值对」列表值必须是字符串同名属性允许出现多次属性名与属性值区分大小写。2.1 顶层属性nix:store_pathProperty描述nix:store_path指定组件对应的 Nix store path。该属性应配合描述该 store path 生产方式的其他属性一起使用例如nix:narinfo:与nix:fod命名空间中的属性。nix:store_path是整棵分类法的锚点它把 SBOM 中的一个抽象组件绑定到 Nix store 中的具体产物而nix:narinfo:与nix:fod两个命名空间则分别从「存储/分发」与「构建/获取」两个角度补充这条 store path 是如何产生的。2.2 两个命名空间Namespace描述nix:narinfo描述组件以 Nix archiveNAR形式存储在二进制缓存binary cache中的专有属性命名空间。nix:fod描述 fixed-output derivation固定输出派生的专有属性命名空间。3.nix:narinfo描述二进制缓存中的组件归档nix:narinfo命名空间的属性用于描述可能从二进制缓存获取的组件归档。它的字段设计直接对标 Nix 二进制缓存的 narinfo 元数据——即nix store/nix-build生态中缓存的.narinfo记录所承载的信息包括归档哈希、大小、压缩格式、签名、内容寻址CA方式等。使用要求一组nix:narinfo属性必须与同一属性列表中的nix:store_path属性配套出现否则外部工具无法知道这些归档元数据对应哪个组件。完整属性表如下Property描述nix:narinfo:store_path该 store 组件对应的 store path。nix:narinfo:urlURL 路径分量。nix:narinfo:nar_hash组件文件系统对象file system object序列化为 Nix archiveNAR后的哈希。nix:narinfo:nar_size组件序列化为 NAR 后的大小。nix:narinfo:compression组件归档所使用的压缩格式。nix:narinfo:file_hash压缩后的组件归档文件本身而非其内部数据的摘要。nix:narinfo:file_size压缩后的组件归档文件本身的大小。nix:narinfo:deriver产出该组件的 derivation 路径。nix:narinfo:system产出该组件所对应的硬件与软件平台。nix:narinfo:sig证明该组件「名副其实」的签名。nix:narinfo:ca该 store 对象文件系统对象的内容地址content address用于计算其 store path。nix:narinfo:references该组件所引用的 store paths以空白符分隔的数组形式表示。这组属性把 Nix 二进制缓存的「物理事实」完整地暴露给 SBOM 消费者外部工具可以据此校验缓存归档的完整性nar_hash/nar_size/file_hash/file_size、追溯其来源deriver/url/system、验证其可信度sig并还原其依赖关系references/ca。4.nix:fod描述固定输出派生nix:fod命名空间描述的是fixed-output derivationFOD——即输出哈希预先声明、从而允许在构建期访问网络的派生。FOD 是 Nixpkgs 中绝大多数源码获取操作fetcher的底层形态因此该命名空间是「从 SBOM 反向复现获取步骤」的关键。4.1 使用规则nix:fod:method属性必填且必须与同一属性列表中的nix:store_path配套出现其余属性均为方法相关method-specific不同的method对应不同的可选属性集合要复现某组件的构建需要把nix:fod:method的值解析为 Nixpkgs 中「参数与给定属性集相交」的对应函数生成nix:fod属性时应选择稳定、参数尽可能少的函数作为 method。关于最后一点文档特别给出了一个实例fetchFromGitHub在 Nixpkgs 中虽然极为常用但生成属性时应将其化简为其底层实现函数fetchzip。4.2 完整属性表Property描述nix:fod:method产生该 FOD 的 Nixpkgs 函数。必填。示例fetchzip、fetchgitnix:fod:namederivation 名称当 method 为fetchzip时存在。nix:fod:refGit ref如分支/标签引用当 method 为fetchgit时存在。nix:fod:revGit rev提交标识当 method 为fetchgit时存在。nix:fod:sha256FOD 哈希。nix:fod:url要获取的 URL。4.3method解析背后的源码依据nix:fod:method的值对应 Nixpkgs 中真实存在的 fetcher 函数文档中给出的两个规范示例fetchzip、fetchgit都有明确的实现支撑fetchzip定义于 pkgs/build-support/fetchzip/default.nix注释明确指出它「下载并解包一个归档文件如 zip 或 tar主要用于 GitHub 的/archive这类动态生成的归档」——因为这类归档解包后的内容稳定而压缩包本身可能因压缩算法或时间戳变化而改变。fetchzip内部通过lib.extendMkDerivation包装fetchurl构造派生支持name、stripRoot、extension、postFetch、recursiveHash等参数其输入语义详见 doc/build-helpers/fetchers.chapter.md 的fetchzip一节fetchgit定义于 pkgs/build-support/fetchgit/default.nix要求url加rev或tag以及hash。从源码可见其哈希处理统一经由lib.fetchers.withNormalizedHash完成将sha256/sha512/hash归一化为outputHash/outputHashAlgo供mkDerivation使用见 lib/fetchers.nix。fetchgit还支持fetchSubmodules、fetchLFS、deepClone、sparseCheckout、fetchTags、rootDir等参数。关于「fetchFromGitHub应化简为fetchzip」这一点可以从 pkgs/build-support/fetchgithub/default.nix 的实现中得到印证其设计默认值是useFetchGit false即默认走fetchzip源码注释「We prefer fetchzip in cases we dont need submodules as the hash [is stable]」明确解释了偏好fetchzip的原因——相比fetchgitfetchzip得到的哈希更稳定只有需要fetchSubmodules、deepClone、fetchLFS、sparseCheckout、rootDir、leaveDotGit等能力时才自动切换到fetchgit。因此 SBOM 生成端把fetchFromGitHub化简为fetchzip本质上就是记录「最小、最稳定」的复现路径避免把fetchFromGitHub这类便捷包装的偶发行为差异带进 SBOM。4.4 从属性还原为 derivation官方示例文档给出了一个将nix:fod属性提取并求值为 derivation 的参考实现其中filterPropertiesToAttrs为示意性虚构函数其作用是把nix:fod:前缀的属性过滤并转换为属性集{ pkgs, filterPropertiesToAttrs, properties, }: let fodProps filterPropertiesToAttrs nix:fod: properties; methods { fetchzip { name, url, sha256, ... }: pkgs.fetchzip { inherit name url sha256; }; }; in methods.${fodProps.method} fodProps这段代码展示了一条清晰的互操作链路SBOM 中记录的nix:fod:method字符串 → Nixpkgs fetcher 函数 → 可求值的 derivation。在实际落地时methods属性集就是 fetcher 分发表而fetchgit分支则对应pkgs.fetchgit { inherit url rev sha256; }这类调用与上文 4.3 节中的函数签名一一对应。4.5 生成nix:fod属性的注意事项综合文档约束与源码行为生成端应遵循以下要点method只填稳定函数优先fetchzip、fetchgit这类底层原语避免fetchFromGitHub等便捷包装属性按方法裁剪fetchzip对应name/url/sha256fetchgit对应url/rev或ref/sha256不要混入无关字段sha256采用 FOD 语义该哈希是派生输出即outputHash的哈希在 Nixpkgs 中默认接受hash与sha256/sha512多种写法统一由 lib/fetchers.nix 的withNormalizedHash归一化始终携带nix:store_path让外部工具能把组件、store path 与复现方式关联起来。5. 实战Nixpkgs 中的 SBOM 生态工具nix命名空间属性分类法的价值在于它能与成熟 SBOM 工具链打通。在当前仓库中即可找到相关的支撑软件包例如pkgs/by-name/cy/cyclonedx-cli/package.nixCycloneDX 官方 CLI用于生成、验证、合并与转换 SBOMpkgs/by-name/cy/cyclonedx-python/package.nixCycloneDX Python 库pkgs/by-name/sy/syft/package.nix基于文件系统的 SBOM 生成器pkgs/by-name/dependency-track 等漏洞管理/依赖分析工具。工作流上可先借助这类工具为软件清单生成标准 CycloneDX SBOM再按本文分类法在组件上追加nix:store_path与对应命名空间的属性最终获得一份「既符合 SBOM 通用规范、又具备 Nix 可复现性语义」的物料清单。需要注意的是本文描述的分类法是文档层面的约定标准Nixpkgs 仓库本身并未内置 SBOM 序列化实现落地时需由生成端按该约定实现。6. OpenXR 互操作NixOS 中的运行时兼容除了 SBOM互操作章节还包含一个面向扩展现实XR的短篇指南doc/interoperability/openxr.md它解决的是另一类互操作问题Nix 应用的动态库加载与 OpenXR 运行时生态的对接。OpenXR 是扩展现实XR应用与驱动provider之间的开放标准。其核心约束在于OpenXR 运行时提供者runtime provider必须保证「运行时的共享库路径」能够被 Nix 应用加载。而在 NixOS 中软件的动态链接依赖默认被打包进 Nix store而非系统全局路径这就带来了加载失败的风险。指南给出的关键建议是如果 OpenXR 运行时提供者运行在FHSEnv中可能需要使用auto-patchelf将依赖链接到 Nix store这样运行时共享库在 FHS 兼容环境中依然能解析到 Nix 化后的依赖路径从而被上层 XR 应用正常加载。关于auto-patchelf的用法可进一步参考 doc/hooks/autopatchelf.section.md它是一个 setup hook通过patchelf自动重写 ELF 二进制/共享库的依赖路径把缺失的运行时依赖替换为 Nix store 中的对应库是 FHSEnv 场景下解决动态链接问题的标准手段。7. 总结Nixpkgs 的互操作性标准章节本质上是为 Nix 生态「出圈」而定义的两套契约CycloneDXnix命名空间属性分类法doc/interoperability/cyclonedx.md——用nix:store_path锚定组件、用nix:narinfo描述二进制缓存归档、用nix:fod描述固定输出派生并辅以「method 解析回 Nixpkgs fetcher」的复现路径让 SBOM 同时具备通用合规性与 Nix 可复现性OpenXR 运行时兼容指南doc/interoperability/openxr.md——通过auto-patchelf保证 FHSEnv 中运行时的共享库能被 Nix 应用加载。这两套约定都遵循同一原则保留 Nix 的精确语义同时以外部标准能消费的形态表达。对生成端而言只要严格遵循属性命名、配套约束与方法选择规则就能产出可被外部工具解析、又能被 Nix 生态回溯的互操作数据。【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nixpkgs 互操作性标准深度解读：CycloneDX SBOM 的 Nix 命名空间属性与 OpenXR 运行时兼容
Nixpkgs 互操作性标准深度解读CycloneDX SBOM 的 Nix 命名空间属性与 OpenXR 运行时兼容【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgsNixpkgs 手册中的「互操作性标准」章节定义了如何将 Nix 特有的信息store path、NAR 归档、fixed-output derivation 等以标准化方式嵌入外部互操作数据格式中使 Nix 产物能被主流软件物料清单SBOM工具与 XR 运行时识别与使用。本文将以该章节为骨架结合 Nixpkgs 仓库内 fetcher 的实际实现系统讲解 CycloneDX SBOM 中nix命名空间属性分类法nix:store_path、nix:narinfo、nix:fod与 OpenXR 运行时兼容指南帮助你在生成 SBOM 或接入 OpenXR 生态时正确表达 Nix 语义。1. 章节定位互操作标准在 Nixpkgs 手册中的角色在 Nixpkgs 文档树中doc/interoperability.md 是「Interoperability Standards」章节的入口文件它在 doc/nav.json 中挂载为手册的一级章节并包含两个子文档doc/interoperability/cyclonedx.md定义 CycloneDX SBOM 中用于承载 Nix 专有信息的属性命名空间doc/interoperability/openxr.md说明 NixOS 中 OpenXR 运行时提供者的共享库加载兼容要求。这两份文档的共同出发点是让 Nix/Nixpkgs 生态产出的构件store 中的组件、二进制缓存归档、派生产物能以可被外部工具解析的形式进入通用的互操作数据格式而不是停留在 Nix 内部闭包图里自成一派。2. CycloneDX 与「nix 命名空间属性分类法」CycloneDX 是由 OWASP 主导的软件物料清单SBOM标准用于记录软件组件、依赖、许可证、漏洞信息等。要让一份 SBOM 同时被 Nix 生态与外部 SBOM 工具理解就需要一套既遵循 CycloneDX 通用结构、又保留 Nix 专有语义的约定——这就是nix命名空间属性分类法nixNamespace Property Taxonomy。分类法建立在 CycloneDX 的 properties组件属性机制之上其基础规则是组件属性是「名-值对」列表值必须是字符串同名属性允许出现多次属性名与属性值区分大小写。2.1 顶层属性nix:store_pathProperty描述nix:store_path指定组件对应的 Nix store path。该属性应配合描述该 store path 生产方式的其他属性一起使用例如nix:narinfo:与nix:fod命名空间中的属性。nix:store_path是整棵分类法的锚点它把 SBOM 中的一个抽象组件绑定到 Nix store 中的具体产物而nix:narinfo:与nix:fod两个命名空间则分别从「存储/分发」与「构建/获取」两个角度补充这条 store path 是如何产生的。2.2 两个命名空间Namespace描述nix:narinfo描述组件以 Nix archiveNAR形式存储在二进制缓存binary cache中的专有属性命名空间。nix:fod描述 fixed-output derivation固定输出派生的专有属性命名空间。3.nix:narinfo描述二进制缓存中的组件归档nix:narinfo命名空间的属性用于描述可能从二进制缓存获取的组件归档。它的字段设计直接对标 Nix 二进制缓存的 narinfo 元数据——即nix store/nix-build生态中缓存的.narinfo记录所承载的信息包括归档哈希、大小、压缩格式、签名、内容寻址CA方式等。使用要求一组nix:narinfo属性必须与同一属性列表中的nix:store_path属性配套出现否则外部工具无法知道这些归档元数据对应哪个组件。完整属性表如下Property描述nix:narinfo:store_path该 store 组件对应的 store path。nix:narinfo:urlURL 路径分量。nix:narinfo:nar_hash组件文件系统对象file system object序列化为 Nix archiveNAR后的哈希。nix:narinfo:nar_size组件序列化为 NAR 后的大小。nix:narinfo:compression组件归档所使用的压缩格式。nix:narinfo:file_hash压缩后的组件归档文件本身而非其内部数据的摘要。nix:narinfo:file_size压缩后的组件归档文件本身的大小。nix:narinfo:deriver产出该组件的 derivation 路径。nix:narinfo:system产出该组件所对应的硬件与软件平台。nix:narinfo:sig证明该组件「名副其实」的签名。nix:narinfo:ca该 store 对象文件系统对象的内容地址content address用于计算其 store path。nix:narinfo:references该组件所引用的 store paths以空白符分隔的数组形式表示。这组属性把 Nix 二进制缓存的「物理事实」完整地暴露给 SBOM 消费者外部工具可以据此校验缓存归档的完整性nar_hash/nar_size/file_hash/file_size、追溯其来源deriver/url/system、验证其可信度sig并还原其依赖关系references/ca。4.nix:fod描述固定输出派生nix:fod命名空间描述的是fixed-output derivationFOD——即输出哈希预先声明、从而允许在构建期访问网络的派生。FOD 是 Nixpkgs 中绝大多数源码获取操作fetcher的底层形态因此该命名空间是「从 SBOM 反向复现获取步骤」的关键。4.1 使用规则nix:fod:method属性必填且必须与同一属性列表中的nix:store_path配套出现其余属性均为方法相关method-specific不同的method对应不同的可选属性集合要复现某组件的构建需要把nix:fod:method的值解析为 Nixpkgs 中「参数与给定属性集相交」的对应函数生成nix:fod属性时应选择稳定、参数尽可能少的函数作为 method。关于最后一点文档特别给出了一个实例fetchFromGitHub在 Nixpkgs 中虽然极为常用但生成属性时应将其化简为其底层实现函数fetchzip。4.2 完整属性表Property描述nix:fod:method产生该 FOD 的 Nixpkgs 函数。必填。示例fetchzip、fetchgitnix:fod:namederivation 名称当 method 为fetchzip时存在。nix:fod:refGit ref如分支/标签引用当 method 为fetchgit时存在。nix:fod:revGit rev提交标识当 method 为fetchgit时存在。nix:fod:sha256FOD 哈希。nix:fod:url要获取的 URL。4.3method解析背后的源码依据nix:fod:method的值对应 Nixpkgs 中真实存在的 fetcher 函数文档中给出的两个规范示例fetchzip、fetchgit都有明确的实现支撑fetchzip定义于 pkgs/build-support/fetchzip/default.nix注释明确指出它「下载并解包一个归档文件如 zip 或 tar主要用于 GitHub 的/archive这类动态生成的归档」——因为这类归档解包后的内容稳定而压缩包本身可能因压缩算法或时间戳变化而改变。fetchzip内部通过lib.extendMkDerivation包装fetchurl构造派生支持name、stripRoot、extension、postFetch、recursiveHash等参数其输入语义详见 doc/build-helpers/fetchers.chapter.md 的fetchzip一节fetchgit定义于 pkgs/build-support/fetchgit/default.nix要求url加rev或tag以及hash。从源码可见其哈希处理统一经由lib.fetchers.withNormalizedHash完成将sha256/sha512/hash归一化为outputHash/outputHashAlgo供mkDerivation使用见 lib/fetchers.nix。fetchgit还支持fetchSubmodules、fetchLFS、deepClone、sparseCheckout、fetchTags、rootDir等参数。关于「fetchFromGitHub应化简为fetchzip」这一点可以从 pkgs/build-support/fetchgithub/default.nix 的实现中得到印证其设计默认值是useFetchGit false即默认走fetchzip源码注释「We prefer fetchzip in cases we dont need submodules as the hash [is stable]」明确解释了偏好fetchzip的原因——相比fetchgitfetchzip得到的哈希更稳定只有需要fetchSubmodules、deepClone、fetchLFS、sparseCheckout、rootDir、leaveDotGit等能力时才自动切换到fetchgit。因此 SBOM 生成端把fetchFromGitHub化简为fetchzip本质上就是记录「最小、最稳定」的复现路径避免把fetchFromGitHub这类便捷包装的偶发行为差异带进 SBOM。4.4 从属性还原为 derivation官方示例文档给出了一个将nix:fod属性提取并求值为 derivation 的参考实现其中filterPropertiesToAttrs为示意性虚构函数其作用是把nix:fod:前缀的属性过滤并转换为属性集{ pkgs, filterPropertiesToAttrs, properties, }: let fodProps filterPropertiesToAttrs nix:fod: properties; methods { fetchzip { name, url, sha256, ... }: pkgs.fetchzip { inherit name url sha256; }; }; in methods.${fodProps.method} fodProps这段代码展示了一条清晰的互操作链路SBOM 中记录的nix:fod:method字符串 → Nixpkgs fetcher 函数 → 可求值的 derivation。在实际落地时methods属性集就是 fetcher 分发表而fetchgit分支则对应pkgs.fetchgit { inherit url rev sha256; }这类调用与上文 4.3 节中的函数签名一一对应。4.5 生成nix:fod属性的注意事项综合文档约束与源码行为生成端应遵循以下要点method只填稳定函数优先fetchzip、fetchgit这类底层原语避免fetchFromGitHub等便捷包装属性按方法裁剪fetchzip对应name/url/sha256fetchgit对应url/rev或ref/sha256不要混入无关字段sha256采用 FOD 语义该哈希是派生输出即outputHash的哈希在 Nixpkgs 中默认接受hash与sha256/sha512多种写法统一由 lib/fetchers.nix 的withNormalizedHash归一化始终携带nix:store_path让外部工具能把组件、store path 与复现方式关联起来。5. 实战Nixpkgs 中的 SBOM 生态工具nix命名空间属性分类法的价值在于它能与成熟 SBOM 工具链打通。在当前仓库中即可找到相关的支撑软件包例如pkgs/by-name/cy/cyclonedx-cli/package.nixCycloneDX 官方 CLI用于生成、验证、合并与转换 SBOMpkgs/by-name/cy/cyclonedx-python/package.nixCycloneDX Python 库pkgs/by-name/sy/syft/package.nix基于文件系统的 SBOM 生成器pkgs/by-name/dependency-track 等漏洞管理/依赖分析工具。工作流上可先借助这类工具为软件清单生成标准 CycloneDX SBOM再按本文分类法在组件上追加nix:store_path与对应命名空间的属性最终获得一份「既符合 SBOM 通用规范、又具备 Nix 可复现性语义」的物料清单。需要注意的是本文描述的分类法是文档层面的约定标准Nixpkgs 仓库本身并未内置 SBOM 序列化实现落地时需由生成端按该约定实现。6. OpenXR 互操作NixOS 中的运行时兼容除了 SBOM互操作章节还包含一个面向扩展现实XR的短篇指南doc/interoperability/openxr.md它解决的是另一类互操作问题Nix 应用的动态库加载与 OpenXR 运行时生态的对接。OpenXR 是扩展现实XR应用与驱动provider之间的开放标准。其核心约束在于OpenXR 运行时提供者runtime provider必须保证「运行时的共享库路径」能够被 Nix 应用加载。而在 NixOS 中软件的动态链接依赖默认被打包进 Nix store而非系统全局路径这就带来了加载失败的风险。指南给出的关键建议是如果 OpenXR 运行时提供者运行在FHSEnv中可能需要使用auto-patchelf将依赖链接到 Nix store这样运行时共享库在 FHS 兼容环境中依然能解析到 Nix 化后的依赖路径从而被上层 XR 应用正常加载。关于auto-patchelf的用法可进一步参考 doc/hooks/autopatchelf.section.md它是一个 setup hook通过patchelf自动重写 ELF 二进制/共享库的依赖路径把缺失的运行时依赖替换为 Nix store 中的对应库是 FHSEnv 场景下解决动态链接问题的标准手段。7. 总结Nixpkgs 的互操作性标准章节本质上是为 Nix 生态「出圈」而定义的两套契约CycloneDXnix命名空间属性分类法doc/interoperability/cyclonedx.md——用nix:store_path锚定组件、用nix:narinfo描述二进制缓存归档、用nix:fod描述固定输出派生并辅以「method 解析回 Nixpkgs fetcher」的复现路径让 SBOM 同时具备通用合规性与 Nix 可复现性OpenXR 运行时兼容指南doc/interoperability/openxr.md——通过auto-patchelf保证 FHSEnv 中运行时的共享库能被 Nix 应用加载。这两套约定都遵循同一原则保留 Nix 的精确语义同时以外部标准能消费的形态表达。对生成端而言只要严格遵循属性命名、配套约束与方法选择规则就能产出可被外部工具解析、又能被 Nix 生态回溯的互操作数据。【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考