Nixpkgs Maintainer Scripts 实战指南get-maintainer.sh 元数据查询与 sha-to-sri.py 哈希格式迁移【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs导读本文聚焦 Nixpkgs 仓库中 maintainers/scripts 目录下维护者常用脚本的实战用法核心讲解两个工具通过 get-maintainer.sh 以任意字段精确查询维护者元数据等价于lib.maintainers.${x} // { handle x; }以及通过 sha-to-sri.py 将 Nix 表达式中旧式十六进制/Nix32/Base64 哈希批量、原子化地改写为 SRI 格式。读完本文你将掌握这两个脚本的全部命令行参数、底层实现原理、配套数据文件结构以及维护者元数据在仓库中的校验与消费方式。目录概览maintainer 工具箱Nixpkgs 的维护者相关脚本统一收纳在 maintainers/scripts 目录下其中包括元数据查询类get-maintainer.sh精确查找维护者信息哈希格式迁移类sha-to-sri.pySRI 哈希格式改写数据校验类check-maintainer-github-handles.sh批量核对 GitHub 用户名有效性辅助数据文件maintainer-list.nix约 3.2 万行的维护者注册表、computed-team-list.nix、github-teams.json等需要特别强调的是README.md 明确声明这些脚本并非稳定接口not a stable interface随时可能被修改或移除。因此在自动化流程或 CI 中引用它们时应做好容错与版本锁定不要把脚本行为当作长期契约。README 也注明其给出的仅是一份远不完整的概览目录内其余脚本如nixpkgs-lint.pl、remove-old-aliases.py等未在文中一一展开。get-maintainer.sh精确查询维护者元数据基本用法与命令格式get-maintainer.sh的命令行格式为get-maintainer.sh [selector] value其中selector指定查询字段value是待匹配的取值。运行后脚本返回一个描述该维护者的 JSON 对象其内容等价于 Nix 表达式lib.maintainers.${x} // { handle x; }即取lib.maintainers属性集中该维护者的完整属性集再并入其属性名handle一并序列化为 JSON。相比用文本搜索直接 grep maintainer-list.nix这种方式能基于真实字段值做精确匹配结果更正确也更健壮。支持的 selector 与匹配规则selector必须是以下取值之一selector匹配依据说明handle默认维护者在lib.maintainers中的属性名不传 selector 时默认使用email维护者对象中的邮箱字段精确匹配name维护者姓名精确匹配githubGitHub 用户名精确匹配githubIdGitHub 用户数字 ID精确匹配数字比较matrixMatrix 用户 ID精确匹配各字段的定义见 maintainer-list.nix 头部注释handle是用于 Nix 表达式中的属性名name是公开姓名github是 GitHub 用户名githubId是 GitHub 数字 ID另有可选的email、matrix与 PGP/GPGkeys指纹列表。实战示例按默认的handle查询不传 selector❯ ./get-maintainer.sh nicoo { email: nicoodebian.org, github: nicoonoclaste, githubId: 1155801, keys: [ { fingerprint: E44E 9EA5 4B8E 256A FB73 49D3 EC9D 3708 72BC 7A8C } ], name: nicoo, handle: nicoo }按姓名查询传入nameselector❯ ./get-maintainer.sh name Silvan Mosberger { email: contactinfinisil.com, github: infinisil, githubId: 20525370, keys: [ { fingerprint: 6C2B 55D4 4E04 8266 6B7D DA1A 422E 9EDA E015 7170 } ], matrix: infinisil:matrix.org, name: Silvan Mosberger, handle: infinisil }从输出可以看到handle字段被合并进结果对象中便于在 JSON 管道里拿到维护者的属性名本身。底层实现nix-instantiate jq 管道查看 get-maintainer.sh 源码一个nix-shell声明式脚本依赖jq与ncurses可以还原其完整调用链数据加载listAsJSON()调用nix-instantiate --eval --strict --json ${MAINTAINERS_DIR}/maintainer-list.nix将 maintainer-list.nix 以 strict json 模式求值得到整个维护者属性集的 JSON 表示。MAINTAINERS_DIR被解析为脚本所在目录的上一级即maintainers/。参数解析parseArgs()接受 1 或 2 个参数参数个数为 1 时selector默认为handle。selector 若不在handle/email/github/githubId/matrix/name之内脚本会列出合法值并以红色错误信息退出set -euo pipefail全程开启。jq 查询构造query()先执行爆炸变换to_entries[] | .value { handle: .key }把{ handle: {...} }形式展开为每条记录 附带 handle 字段的流再按 selector 构造select表达式。值得注意的实现细节是githubId使用数字比较select(.githubId $value)而其余字段均按字符串比较select(.${selector} $value)这与githubId在maintainer-list.nix中是整数、其余字段是字符串的数据类型完全对应。执行过滤最终通过jq -e执行$explode | $select-e保证在无匹配输出为空时返回非零退出码方便在脚本中做错误处理。源码中还留有一条 TODO 注释说明name字段目前不支持近似匹配。数据源maintainer-list.nix 与 lib 集成查询的数据源头 maintainer-list.nix 本身就是 Nixpkgs 中lib.maintainers的定义所在lib/default.nix 中的maintainers import ../maintainers/maintainer-list.nix;将其挂入lib.maintainers因此get-maintainer.sh的返回等价于对lib.maintainers.${x}的求值。该文件要求字段保持字母序排列keep-sorted并且维护者注册遵循必须有 GitHub 账号的硬性约定——因为新维护者会被邀请加入NixOS/nixpkgs-maintainers团队、可被请求 review、CI 也会对由其维护的包请求其审查。配套的数据完整性校验位于 lib/tests/maintainers.nix运行nix-build lib/tests/release.nix即可执行其检查项包括指定了github就必须同时提供githubId缺失时脚本会调用 GitHub API 反查 ID 并打印修正提示email、github、matrix三者至少提供其一确保维护者可被联系到邮箱不得使用noreply.github.com这类不可达地址github、githubId、email、matrix在全表中必须唯一否则lib.maintainers求值直接抛错。sha-to-sri.py哈希属性到 SRI 格式的批量迁移背景为什么需要 SRI 哈希Nix 表达式中固定输出派生式的哈希历史上存在多种写法十六进制串、Nix 特有的 nix32 字母表串、Base64 串且属性名可能是hash、sha1、sha256或sha512之一。sha-to-sri.py的作用是把这些旧格式统一改写为 SRISubresource Integrity格式形如hash sha256-{base64 encoded value};即{hash name}-{base64 编码后的摘要}。SRI 格式自带哈希算法前缀消除了歧义这也是当前 Nixpkgs 推荐并广泛采用的写法。命令行用法sha-to-sri.py path ...path可以指向单个 Nix 文件也可以指向目录——目录会被自动递归遍历实际仅处理其中**/*.nix文件可同时传入多个path脚本会原子化改写匹配到的哈希属性先在原文件同目录创建临时文件写入新内容成功后再替换原文件保证中途失败不会破坏原文件见源码 atomicFileUpdate 的实现使用NamedTemporaryFile写入正常退出时tmpPath.replace(target)完成原子替换异常时删除临时文件并抛出。匹配与改写规则从源码看sha-to-sri.py 使用正则_DEF_RE匹配形如sha256 ...的属性定义具体规则属性名支持hash与sha1、sha256、sha512README 摘要所述源码中_HASHES实际启用的是 SHA-256 与 SHA-512 两套算法族值可以是十六进制长度 2n、Nix 的 nix32 编码长度1 (8*n)/5字母表0123456789abcdfghijklmnpqrsvwxyz注意无e、o、t、u或Base64含标准填充改写时把摘要解码为原始字节再重新以f{hashName}-{base64}形式输出值两侧的引号单引号或双引号会被保留并围绕新值重新闭合。例如仓库 pkgs/by-name/_0/_0x/package.nix 中的 SRI 写法hash sha256-im9F0MQYddCcBthSldeQ6T0BIswhBSGc/LKUlJg/754;就是本脚本目标形态的典型样例——算法名sha256与-前缀加上 Base64 摘要。自动跳过策略sha-to-sri.py内置了两层跳过机制防止误改自动生成的文件内容启发式若文件首个非空行包含generated by或do not edit大小写不敏感则整文件跳过目录遍历启发式递归目录时文件名恰为yarn.nix源码中另有gemset.nix或文件名含generated的文件一律跳过。该策略对应源码中的_SKIP_RE与_IGNORE集合同时_IGNORE对yarn.nix、gemset.nix的排除也保护了由打包工具自动生成的依赖锁定文件。运行环境脚本头部是 nix-shell shebang#! nix-shell -i python3 -I -p python3.withPackages(p: p; [ rich structlog ])依赖python3隔离模式-I、rich与structlog用于结构化日志输出因此可以直接以./sha-to-sri.py path方式在装有 Nix 的环境中运行无需手工准备虚拟环境。延伸维护者数据的其他消费方式maintainer-list.nix 头部注释推荐阅读 check-maintainer-github-handles.sh 作为如何消费lib.maintainers数据的示例。该脚本展示了另一条更重型的查询路径nix-instantiate -A lib.maintainers --eval --strict --json \ | jq -r .[]|.github|select(.) \ | parallel -j5 checkUser它通过nix-instantiate -A lib.maintainers直接取出整个维护者集合用 jq 提取所有 GitHub 用户名再以parallel并发向 GitHub 发起请求检查用户名是否有效404 即失效以及该用户在 Nixpkgs 是否有提交记录用于清理失效维护者条目。这与get-maintainer.sh的单点精确查询形成互补一个面向全量扫描一个面向精确检索。小结查询维护者元数据使用 get-maintainer.sh支持handle默认、email、name、github、githubId、matrix六种 selector 的精确匹配返回带handle字段的完整 JSON其实现依托nix-instantiate --eval --strict --json求值 maintainer-list.nix 后交给 jq 过滤。统一哈希格式使用 sha-to-sri.py对单个 Nix 文件或目录递归改写hash/sha(1|256|512)为 SRI 格式原子化写入并自动跳过自动生成文件与yarn.nix/gemset.nix。牢记非稳定接口以上脚本仅面向 Nixpkgs 维护者日常工作不提供稳定性保证README 明确其可能随时变更或移除自动化引用时务必注意。【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Nixpkgs Maintainer Scripts 实战指南：get-maintainer.sh 元数据查询与 sha-to-sri.py 哈希格式迁移
Nixpkgs Maintainer Scripts 实战指南get-maintainer.sh 元数据查询与 sha-to-sri.py 哈希格式迁移【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs导读本文聚焦 Nixpkgs 仓库中 maintainers/scripts 目录下维护者常用脚本的实战用法核心讲解两个工具通过 get-maintainer.sh 以任意字段精确查询维护者元数据等价于lib.maintainers.${x} // { handle x; }以及通过 sha-to-sri.py 将 Nix 表达式中旧式十六进制/Nix32/Base64 哈希批量、原子化地改写为 SRI 格式。读完本文你将掌握这两个脚本的全部命令行参数、底层实现原理、配套数据文件结构以及维护者元数据在仓库中的校验与消费方式。目录概览maintainer 工具箱Nixpkgs 的维护者相关脚本统一收纳在 maintainers/scripts 目录下其中包括元数据查询类get-maintainer.sh精确查找维护者信息哈希格式迁移类sha-to-sri.pySRI 哈希格式改写数据校验类check-maintainer-github-handles.sh批量核对 GitHub 用户名有效性辅助数据文件maintainer-list.nix约 3.2 万行的维护者注册表、computed-team-list.nix、github-teams.json等需要特别强调的是README.md 明确声明这些脚本并非稳定接口not a stable interface随时可能被修改或移除。因此在自动化流程或 CI 中引用它们时应做好容错与版本锁定不要把脚本行为当作长期契约。README 也注明其给出的仅是一份远不完整的概览目录内其余脚本如nixpkgs-lint.pl、remove-old-aliases.py等未在文中一一展开。get-maintainer.sh精确查询维护者元数据基本用法与命令格式get-maintainer.sh的命令行格式为get-maintainer.sh [selector] value其中selector指定查询字段value是待匹配的取值。运行后脚本返回一个描述该维护者的 JSON 对象其内容等价于 Nix 表达式lib.maintainers.${x} // { handle x; }即取lib.maintainers属性集中该维护者的完整属性集再并入其属性名handle一并序列化为 JSON。相比用文本搜索直接 grep maintainer-list.nix这种方式能基于真实字段值做精确匹配结果更正确也更健壮。支持的 selector 与匹配规则selector必须是以下取值之一selector匹配依据说明handle默认维护者在lib.maintainers中的属性名不传 selector 时默认使用email维护者对象中的邮箱字段精确匹配name维护者姓名精确匹配githubGitHub 用户名精确匹配githubIdGitHub 用户数字 ID精确匹配数字比较matrixMatrix 用户 ID精确匹配各字段的定义见 maintainer-list.nix 头部注释handle是用于 Nix 表达式中的属性名name是公开姓名github是 GitHub 用户名githubId是 GitHub 数字 ID另有可选的email、matrix与 PGP/GPGkeys指纹列表。实战示例按默认的handle查询不传 selector❯ ./get-maintainer.sh nicoo { email: nicoodebian.org, github: nicoonoclaste, githubId: 1155801, keys: [ { fingerprint: E44E 9EA5 4B8E 256A FB73 49D3 EC9D 3708 72BC 7A8C } ], name: nicoo, handle: nicoo }按姓名查询传入nameselector❯ ./get-maintainer.sh name Silvan Mosberger { email: contactinfinisil.com, github: infinisil, githubId: 20525370, keys: [ { fingerprint: 6C2B 55D4 4E04 8266 6B7D DA1A 422E 9EDA E015 7170 } ], matrix: infinisil:matrix.org, name: Silvan Mosberger, handle: infinisil }从输出可以看到handle字段被合并进结果对象中便于在 JSON 管道里拿到维护者的属性名本身。底层实现nix-instantiate jq 管道查看 get-maintainer.sh 源码一个nix-shell声明式脚本依赖jq与ncurses可以还原其完整调用链数据加载listAsJSON()调用nix-instantiate --eval --strict --json ${MAINTAINERS_DIR}/maintainer-list.nix将 maintainer-list.nix 以 strict json 模式求值得到整个维护者属性集的 JSON 表示。MAINTAINERS_DIR被解析为脚本所在目录的上一级即maintainers/。参数解析parseArgs()接受 1 或 2 个参数参数个数为 1 时selector默认为handle。selector 若不在handle/email/github/githubId/matrix/name之内脚本会列出合法值并以红色错误信息退出set -euo pipefail全程开启。jq 查询构造query()先执行爆炸变换to_entries[] | .value { handle: .key }把{ handle: {...} }形式展开为每条记录 附带 handle 字段的流再按 selector 构造select表达式。值得注意的实现细节是githubId使用数字比较select(.githubId $value)而其余字段均按字符串比较select(.${selector} $value)这与githubId在maintainer-list.nix中是整数、其余字段是字符串的数据类型完全对应。执行过滤最终通过jq -e执行$explode | $select-e保证在无匹配输出为空时返回非零退出码方便在脚本中做错误处理。源码中还留有一条 TODO 注释说明name字段目前不支持近似匹配。数据源maintainer-list.nix 与 lib 集成查询的数据源头 maintainer-list.nix 本身就是 Nixpkgs 中lib.maintainers的定义所在lib/default.nix 中的maintainers import ../maintainers/maintainer-list.nix;将其挂入lib.maintainers因此get-maintainer.sh的返回等价于对lib.maintainers.${x}的求值。该文件要求字段保持字母序排列keep-sorted并且维护者注册遵循必须有 GitHub 账号的硬性约定——因为新维护者会被邀请加入NixOS/nixpkgs-maintainers团队、可被请求 review、CI 也会对由其维护的包请求其审查。配套的数据完整性校验位于 lib/tests/maintainers.nix运行nix-build lib/tests/release.nix即可执行其检查项包括指定了github就必须同时提供githubId缺失时脚本会调用 GitHub API 反查 ID 并打印修正提示email、github、matrix三者至少提供其一确保维护者可被联系到邮箱不得使用noreply.github.com这类不可达地址github、githubId、email、matrix在全表中必须唯一否则lib.maintainers求值直接抛错。sha-to-sri.py哈希属性到 SRI 格式的批量迁移背景为什么需要 SRI 哈希Nix 表达式中固定输出派生式的哈希历史上存在多种写法十六进制串、Nix 特有的 nix32 字母表串、Base64 串且属性名可能是hash、sha1、sha256或sha512之一。sha-to-sri.py的作用是把这些旧格式统一改写为 SRISubresource Integrity格式形如hash sha256-{base64 encoded value};即{hash name}-{base64 编码后的摘要}。SRI 格式自带哈希算法前缀消除了歧义这也是当前 Nixpkgs 推荐并广泛采用的写法。命令行用法sha-to-sri.py path ...path可以指向单个 Nix 文件也可以指向目录——目录会被自动递归遍历实际仅处理其中**/*.nix文件可同时传入多个path脚本会原子化改写匹配到的哈希属性先在原文件同目录创建临时文件写入新内容成功后再替换原文件保证中途失败不会破坏原文件见源码 atomicFileUpdate 的实现使用NamedTemporaryFile写入正常退出时tmpPath.replace(target)完成原子替换异常时删除临时文件并抛出。匹配与改写规则从源码看sha-to-sri.py 使用正则_DEF_RE匹配形如sha256 ...的属性定义具体规则属性名支持hash与sha1、sha256、sha512README 摘要所述源码中_HASHES实际启用的是 SHA-256 与 SHA-512 两套算法族值可以是十六进制长度 2n、Nix 的 nix32 编码长度1 (8*n)/5字母表0123456789abcdfghijklmnpqrsvwxyz注意无e、o、t、u或Base64含标准填充改写时把摘要解码为原始字节再重新以f{hashName}-{base64}形式输出值两侧的引号单引号或双引号会被保留并围绕新值重新闭合。例如仓库 pkgs/by-name/_0/_0x/package.nix 中的 SRI 写法hash sha256-im9F0MQYddCcBthSldeQ6T0BIswhBSGc/LKUlJg/754;就是本脚本目标形态的典型样例——算法名sha256与-前缀加上 Base64 摘要。自动跳过策略sha-to-sri.py内置了两层跳过机制防止误改自动生成的文件内容启发式若文件首个非空行包含generated by或do not edit大小写不敏感则整文件跳过目录遍历启发式递归目录时文件名恰为yarn.nix源码中另有gemset.nix或文件名含generated的文件一律跳过。该策略对应源码中的_SKIP_RE与_IGNORE集合同时_IGNORE对yarn.nix、gemset.nix的排除也保护了由打包工具自动生成的依赖锁定文件。运行环境脚本头部是 nix-shell shebang#! nix-shell -i python3 -I -p python3.withPackages(p: p; [ rich structlog ])依赖python3隔离模式-I、rich与structlog用于结构化日志输出因此可以直接以./sha-to-sri.py path方式在装有 Nix 的环境中运行无需手工准备虚拟环境。延伸维护者数据的其他消费方式maintainer-list.nix 头部注释推荐阅读 check-maintainer-github-handles.sh 作为如何消费lib.maintainers数据的示例。该脚本展示了另一条更重型的查询路径nix-instantiate -A lib.maintainers --eval --strict --json \ | jq -r .[]|.github|select(.) \ | parallel -j5 checkUser它通过nix-instantiate -A lib.maintainers直接取出整个维护者集合用 jq 提取所有 GitHub 用户名再以parallel并发向 GitHub 发起请求检查用户名是否有效404 即失效以及该用户在 Nixpkgs 是否有提交记录用于清理失效维护者条目。这与get-maintainer.sh的单点精确查询形成互补一个面向全量扫描一个面向精确检索。小结查询维护者元数据使用 get-maintainer.sh支持handle默认、email、name、github、githubId、matrix六种 selector 的精确匹配返回带handle字段的完整 JSON其实现依托nix-instantiate --eval --strict --json求值 maintainer-list.nix 后交给 jq 过滤。统一哈希格式使用 sha-to-sri.py对单个 Nix 文件或目录递归改写hash/sha(1|256|512)为 SRI 格式原子化写入并自动跳过自动生成文件与yarn.nix/gemset.nix。牢记非稳定接口以上脚本仅面向 Nixpkgs 维护者日常工作不提供稳定性保证README 明确其可能随时变更或移除自动化引用时务必注意。【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
