执行摘要

• 一句话：修复 PyPI 发布工作流，支持手动调度和 manylinux 打包
• 推荐动作：该 PR 值得合并，解决了 PyPI 发布流程中的关键问题。建议开发者在手动发布时注意输入正确的版本号。

功能与动机

此前 PyPI 发布工作流仅支持标签触发，手动运行分支时 setuptools-scm 会解析出包含 .devN+gHASH 的版本号，被 PyPI 拒绝；同时直接构建的 wheel 带有 linux_x86_64 平台标签，PyPI 要求兼容 manylinux 标签。本 PR 通过添加 workflow_dispatch 输入参数以固定版本号，并增加 protoc 安装和 auditwheel 修复步骤来解决这些问题。

实现拆解

1. 新增手动调度输入：在 release-pypi.yml 的 workflow_dispatch 触发条件中添加 version 输入字段（字符串类型），用于手动运行时指定发布版本。
2. 安装 protoc 依赖：增加 Install protoc 步骤，安装 protoc，以满足 setuptools-rust 构建原生 gRPC 扩展的编译需求。
3. 构建阶段版本锁定：在 Build wheel 步骤中，若 RELEASE_VERSION 环境变量非空（来自手动输入的 version），则设置 SETUPTOOLS_SCM_PRETEND_VERSION，去除版本前缀 'v' 后传递给 setuptools-scm，确保 wheel 版本号正确。
4. auditwheel 修复平台标签：新增 Repair wheel for manylinux 步骤，使用 auditwheel 将 linux_x86_64 平台标签重写为 manylinux_* 标签，并重新打包，以满足 PyPI 的平台兼容要求。
5. 上传前整理产物：将修复后的 wheel 移动至 dist 目录，然后执行 twine upload 上传。

关键文件：

• .github/workflows/release-pypi.yml（模块 CI 工作流；类别 infra；类型 infrastructure）: PR 唯一变更文件，完成所有修复：添加 workflow_dispatch 输入、protoc 安装、版本锁定和 auditwheel 修复。

关键符号：未识别

评论区精华

该 PR 无 review 评论，变更由作者独立完成并合并。提交历史显示经过 4 次迭代，从最初的简单修复逐步演进到包含版本锁定和 manylinux 修复的完整方案。

• 暂无高价值评论线程

风险与影响

• 风险：主要风险在于手动输入版本号可能与人手误差（如输入不存在的版本），但输入仅用于手动调度，不会自动触发；auditwheel 修复步骤可能引入对系统 glibc 版本的依赖（Ubuntu 24.04 的 glibc 2.39 决定了 manylinux 策略），但在受控 CI 运行环境中风险可控。
• 影响：直接影响 PyPI 发布流程，支持手动调度发布和确保 wheel 符合 PyPI 平台要求。对现有自动标签触发流程无影响（新增步骤仅对手动调度生效）。
• 风险标记：手动输入版本号可能出错, auditwheel 依赖系统 glibc 版本

关联脉络

• PR #24385 Fix sgl-deep-gemm release workflow: 同为修复发布流程的 PR，但针对不同的包（deep-gemm），体现了仓库对多个发布工作流的持续维护。