执行摘要

• 一句话：将音频依赖 pyav 和 soundfile 从通用要求移回音频可选包，避免 LGPL 许可问题。
• 推荐动作：该 PR 变更直接，无需深入精读。值得关注的点是团队对许可合规的重视，以及依赖分类的决策（通用 vs 可选）。对于涉及音频功能的开发者，需注意安装指令的变化。

功能与动机

根据 PR body 中引用的 Slack 讨论链接，撤销 PR #39997 的动机是避免引入 LGPL 许可的 soxr 依赖（来自 mistral-common[audio]）。原 PR 的目的是让大多数音频模型无需安装额外的音频依赖即可工作，但移动 pyav 和 soundfile 到通用要求可能无意中引入了许可风险。

实现拆解

1. 恢复音频可选包依赖：在 setup.py 的 extras_require 字典中，将 "av" 和 "soundfile" 添加回 "audio" 列表，确保它们仅在使用音频功能时安装。
2. 从通用要求中移除：在 requirements/common.txt 中删除 av 和 soundfile 行，防止它们成为所有安装的强制依赖。
3. 同步测试配置：更新 requirements/test/rocm.txt，移除对通用要求的冗余引用，确保测试环境依赖关系正确。

关键文件：

• setup.py（模块 包配置；类别 source；类型 configuration）: 定义包的可选依赖，是依赖管理的核心入口。
• requirements/common.txt（模块 依赖管理；类别 config；类型 configuration）: 定义所有安装的通用依赖，移除非必需音频库以简化默认安装。
• requirements/test/rocm.txt（模块 测试配置；类别 config；类型 configuration）: ROCm 测试环境的依赖锁定文件，更新以反映依赖来源变化。

关键符号：未识别

关键源码片段

setup.py

定义包的可选依赖，是依赖管理的核心入口。

# setup.py 中 extras_require 字典的音频部分
extras_require={
    # ... 其他可选包 ...
    "audio": [
        "av", # 重新添加：用于音频处理的 pyav 库
        "scipy", # 保留：phi4-mm 等模型所需
        "soundfile", # 重新添加：音频文件 I/O 支持
        "mistral_common[audio]", # 保留：voxtral 模型所需，可能引入 LGPL 许可的 soxr
    ], # 注释：音频处理所需依赖，现在仅当用户安装 vllm[audio] 时才会安装
    "video": [], # 保持向后兼容
    # ... 其他可选包 ...
},

评论区精华

review 中没有实质性技术讨论，只有自动化机器人的评论和简单的批准。gemini-code-assist[bot] 的评论总结了变更内容：“将 av 和 soundfile 依赖从通用要求移至音频可选包，确保这些音频相关库仅在明确请求音频功能时安装。” 两位人工审核者（ywang96 和 yewentao256）直接批准，未提出疑问或争议。

• 依赖移动的总结 (design): 变更被接受，无争议。

风险与影响

• 风险：低风险。变更主要涉及依赖管理，不触及核心运行时逻辑。风险包括：
  • 依赖兼容性：将 pyav 和 soundfile 移回可选包后，未显式安装音频依赖的用户可能无法使用音频功能，但这符合设计意图。
  • 测试覆盖：ROCm 测试要求文件的更新确保了测试环境的一致性，但未看到直接针对此变更的单元测试。
  • 许可合规：撤销变更避免了潜在的 LGPL 许可问题，降低了法律风险。
  • 影响：影响范围有限。对用户的影响：音频功能现在需要显式安装 vllm[audio]，增加了使用门槛，但避免了不必要的许可暴露。对系统的影响：减少了默认安装的依赖数量，可能略微简化部署。对团队的影响：维护了依赖管理的清晰性，符合“可选功能应有可选依赖”的原则。
  • 风险标记：依赖管理变更, 许可合规调整

关联脉络

• PR #39997 [Misc] Move pyav and soundfile to common requirements: 本 PR 直接撤销了 #39997 的变更，两者是互逆操作，涉及相同的文件和依赖管理逻辑。