CLI存储【免费下载链接】nvme-cliNVMe management command line interface.项目地址https://gitcode.com/gh_mirrors/nv/nvme-cli点击查看免费下载libnvme3 是 nvme-cli 仓库中面向 Python 的 SWIG 绑定包本文以其发布说明libnvme/libnvme3/PUBLISHING.md为核心结合 .github/workflows/libnvme-release-python.yml 与 pyproject.toml 等仓库实现完整讲解 libnvme3 的发布机制、版本号生成逻辑、构建与验证流程以及维护者如何通过 TestPyPI 测试发布、如何触发正式 PyPI 发布、如何安装验证产物。读完本文你将掌握该包零手工 twine 命令、全自动化的发布模型并能在本地复现构建与安装验证步骤。一、发布对象为什么只发 sdist 而不发 wheellibnvme3 的 PyPI 发布只包含源码发行版sdist不产出二进制 wheel。这一点在 libnvme/libnvme3/PUBLISHING.md 中明确指出原因可以从包的构建方式得到印证pyproject.toml 使用mesonpy作为构建后端build-system.requires声明了meson-python、meson、ninja和swig四类构建依赖sdist 内包含 libnvme3 的完整源码树安装时在目标机器上现场编译先用 SWIG 从.i接口文件生成 Python 包装代码再经 Meson/Ninja 编译 C 库与绑定[tool.meson-python.args]的setup段显式传入-Dnvmedisabled -Dlibnvmeenabled -Dpythonenabled -Dpypitrue等 Meson 选项确保只构建库与 Python 绑定而不构建 nvme-cli 命令行工具本身。由此带来一个重要使用前提最终用户在pip install libnvme3时机器上必须预先具备 C 编译器、Meson、Ninja、SWIG 以及 libnvme 的 C 依赖否则安装会失败。这也是 libnvme/libnvme3/README.md 中优先从发行版软件仓库安装如 Debian/Ubuntu 的apt-get install python3-libnvme3、Fedora 的dnf install python3-libnvme3、openSUSE 的zypper install python3-libnvme3的原因。二、发布机制总览GitHub Actions 全自动接管发布流程完全由 GitHub Actions 工作流驱动不需要任何人手工执行twine或pip发布命令。核心工作流是 .github/workflows/libnvme-release-python.yml名为Release Python其触发条件为push 到master分支对应开发版发布通道push 任意 tag对应正式版发布通道且 tag 需满足版本格式校验支持workflow_dispatch手动触发可指定tag输入参数。工作流内部划分为四个 job形成两条发布链路Job职责所属链路build_sdist构建正式版 sdist 并校验正式版 → PyPIbuild_test_sdist基于git describe计算 dev 版本、构建开发版 sdist 并校验开发版 → TestPyPIupload_test_pypi将开发版 sdist 发布到 TestPyPI开发版 → TestPyPIupload_pypi将正式版 sdist 发布到 PyPI正式版 → PyPI两条链路的依赖关系为upload_test_pypi依赖build_test_sdistupload_pypi依赖build_sdist。也就是说每次 push 到 master 都会先构建开发版并发布到 TestPyPI只有 tag 推送才会走正式版构建与 PyPI 发布。三、开发版通道每次 push 到 master 即发布到 TestPyPI3.1 触发与条件upload_test_pypijob 的触发条件包含两个关键约束见 .github/workflows/libnvme-release-python.ymlif: github.repository linux-nvme/nvme-cli github.ref_type branch即只有主仓库的分支推送才会真正上传到 TestPyPI——fork 仓库中的 push 虽然会触发构建 job但不会执行上传这避免了 fork 污染测试索引。3.2 dev 版本号如何生成开发版的版本号并非固定值而是由git describe动态推导。build_test_sdistjob 的关键逻辑.github/workflows/libnvme-release-python.ymlgit describe --tags --abbrev0取得最近一个 tag例如v3.0git rev-list HEAD --count取得自仓库起点以来的提交总数例如123去掉 tag 的v前缀拼接为${BASE_VERSION}.dev${REV}得到形如3.0.dev123的开发版本号用sed把该版本号写回meson.build的project(version: ...)字段并提交一次ci: set project version to ...的版本号 bump commit。注意该 job 使用fetch-depth: 0检出完整历史这正是git describe计算版本号的前提。由于每次 push 的提交数不同每个 dev 版本号都是唯一的、可追溯的不会覆盖 TestPyPI 上已有的同名版本。3.3 从 TestPyPI 安装验证开发版发布后维护者或其他开发者可安装验证命令来自 libnvme/libnvme3/PUBLISHING.mdpip install \ --index-url https://test.pypi.org/simple/ \ --extra-index-url https://pypi.org/simple/ \ libnvmeversion其中version需替换为实际推导出的开发版本号如3.0.dev123。同时指定两个索引的原因libnvme3 的构建依赖如 meson-python 等大多只存在于正式 PyPI因此--extra-index-url https://pypi.org/simple/保证依赖也能被解析到而包本身优先从 TestPyPI 拉取从而验证待发布内容。四、正式版通道推送版本 tag 即发布到 PyPI4.1 触发条件与 tag 格式校验正式版发布由upload_pypijob 承担.github/workflows/libnvme-release-python.yml其约束为if: startsWith(github.ref, refs/tags/v) github.repository linux-nvme/nvme-cli此外job 内还有一步更严格的 tag 正则校验if [[ ${{ github.ref }} ~ ^refs/tags/v([0-9]\.[0-9])(\.[0-9])?(rc[0-9])?$ ]]; then这意味着 tag 必须匹配vX.Y、vX.Y.Z或带 RC 后缀的vX.YrcN/vX.Y.ZrcN形式才会下载 sdist 产物并发布到 PyPI。不匹配的 tag如vX.Y.Z-beta会被静默跳过不会产生发布。PUBLISHING.md 中提到的tag 匹配vX.Y或vX.Y.Z正是这条正则的文档化表述。4.2 发布认证OIDC无需 API Token两个上传 job 都声明了permissions: id-token: write并运行于environment: pypi。这表示发布动作使用OIDCOpenID Connect身份联合认证GitHub Actions 以工作流身份直接换取 PyPI 的短期令牌仓库中无需存储任何 PyPI API Token 作为发布凭据。这是 PUBLISHING.md 中Publishing uses OIDC (id-token: write) — no API token is required的实现依据。整个仓库中需要显式 Token 的仅有测试索引清理场景见下文第六节。五、构建与校验环节buildtwine check双重把关无论开发版还是正式版sdist 在发布前都经过相同两道工序.github/workflows/libnvme-release-python.ymlpipx run build --sdist # 用 PyPA build 前端构建源码发行版 pipx run twine check dist/*.tar.gz # 校验 sdist 元数据与格式build --sdist是 PEP 517 标准构建前端会读取 pyproject.toml 中声明的mesonpy后端并现场执行构建twine check负责校验包元数据的规范性与 README 渲染等只有通过校验的产物才会进入上传步骤构建产物以 artifact 形式上载并保留 5 天retention-days: 5供upload_*job 下载后发布。两套构建分别运行在ghcr.io/linux-nvme/debian:latest正式版与ghcr.io/linux-nvme/debian.python:latest开发版容器镜像中并使用固定的 Python 3.10 环境PYTHON_VERSION: 3.10。六、配套的清理工作流控制 TestPyPI 上的 dev 版本数量由于每次 push 都会向 TestPyPI 发布一个新 dev 版本长期积累会形成大量历史版本。仓库为此提供了配套工作流 .github/workflows/libnvme-cleanup-python.ymlCleanup Python dev releases用于按需清理仅支持workflow_dispatch手动触发两个输入参数keep-last保留最近多少个 dev 版本默认 5与dry-run默认true只模拟不删除实现上使用pypi-cleanup工具针对包名libnvme3、版本正则.*\.dev[0-9]对 TestPyPI 上超出保留数量的 dev 版本执行删除与发布链路不同该工作流需要PYPI_API_TOKEN存储在TEST_PYPI_API_TOKENsecret 中因为它通过 API 执行删除操作而非 OIDC 身份联合。七、维护者操作速查综合以上机制面向 libnvme3 发布维护者的完整操作清单如下日常开发直接 push 到master。CI 会自动构建X.Y.devN版本并发布到 TestPyPI无需任何手工操作验证开发版按第三节的命令从 TestPyPI 安装对应版本验证绑定功能可结合 libnvme/libnvme3/tests 下的测试脚本如test-objects.py、test-config.py做功能回归发布正式版推送符合vX.Y/vX.Y.Z/vX.YrcN格式的 tag。CI 自动构建、校验并发布到 PyPI清理测试索引若 TestPyPI 上 dev 版本过多手动触发 .github/workflows/libnvme-cleanup-python.yml先以dry-runtrue预览再关闭 dry-run 实际清理最终用户安装pip install libnvme3需预装 C 编译器、Meson、Ninja、SWIG 及 libnvme C 依赖更推荐通过发行版包管理器安装python3-libnvme3。八、小结libnvme3 的发布体系是一个完全自动化的双通道模型master 分支推送 → 动态 dev 版本 → TestPyPI版本 tag 推送 → 正式版本 → PyPI全程由 .github/workflows/libnvme-release-python.yml 驱动构建统一走 PEP 517 的build --sdisttwine check上传认证统一走 OIDC。维护者唯一需要掌握的手工动作是选择合适的 tag 格式与可选地运行清理工作流。理解这套机制后无论是参与 nvme-cli 的 Python 绑定开发还是为 libnvme3 打一个正式 release都能准确预判 CI 行为与产物去向。赞分享CLI存储【免费下载链接】nvme-cliNVMe management command line interface.项目地址https://gitcode.com/gh_mirrors/nv/nvme-cli点击查看免费下载相关推荐Tkinter-Designer 包发布实战基于 Poetry 的 PyPI 与 TestPyPI 发布全流程指南Tkinter Designer 包发布实战基于 Poetry 的 PyPI 与 TestPyPI 发布全流程指南 导读 本文以 docs/instructi开发工具代码生成低代码MindSpeed/Qwen3-1.7B-Base安全部署策略企业级AI应用的安全最佳实践MindSpeed/Qwen3 1.7B Base安全部署策略企业级AI应用的安全最佳实践 在企业级AI应用部署中确保MindSpeed/Qwen3 1.7使用 Poetry 构建并发布 Tkinter-Designer CLI 到 PyPI从 testpypi 验证到历史打包流程全解析使用 Poetry 构建并发布 Tkinter Designer CLI 到 PyPI从 testpypi 验证到历史打包流程全解析 本文基于 Tkinter开发工具代码生成低代码上一篇Claude Code Game Studios 中的 dev-story 技能从故事到代码的完整实现流水线下一篇酱椒蒜香片片鱼复刻指南黑鱼片蒸菜的配料、汆烫与蒸制标准化全流程CookLikeHOC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考