摘要

  • PyPI 将 yank 说明为删除之外的非破坏性选择；管理界面目前针对整个 release，而索引可在文件链接上呈现状态。
  • PEP 592 的 data-yanked 可被取消或再次设置；它不是某次解析、下载或安全结论的记录。
  • 重要判断应把仓库状态、依赖约束、解析器选择、获得的文件及部署证据分开保存。

“已撤回”很容易被读成“已被完全收回”。PyPI 给出的语境更窄：版本损坏、不能安装、违反自身兼容性承诺或含有安全漏洞，都是维护者可以考虑 yank 的原因。原因是可能性清单，不是该标记自动携带的判定。即使维护者写下说明，那也是供下游理解的背景，不能代替漏洞确认、事故调查或对每个使用者的指令。

仓库层也有明确边界。PyPI 当前的管理动作按整个 release 进行；PEP 592 则在 Simple API 的链接上定义 data-yanked。同一动作可以在客户端看到文件层的信号，但这不产生删除凭据、发布者授权变更，或某台机器实际获得了文件的证明。JSON API 的 yanked 和 yanked_reason 同样只是索引观察。

真正的选择发生在另一层。PEP 592 要求安装器在存在满足约束的未 yank 版本时忽略 yanked 版本，也允许实现即使没有可用替代也拒绝它。PyPI 对精确版本的说明不能抹去客户端政策、锁文件、索引视图和时间的影响。要说某个环境选择了什么，至少需要当时的约束或锁、工具版本和设置、可见的索引、警告、最终文件哈希。当前的标记无法倒推过去的解析过程。

删除也不能与 yank 混为一谈。PyPI 明确说 yank 不释放存储；删除在无管理员干预下不可逆，并可能破坏固定版本的下游依赖。因此“文件仍在”不是认可，“标记为 yanked”也不是到处消失。它既不能证明某个包安全，也不能证明不安全。

Daniel Kade 建议保留五段收据：带时间的项目/版本和索引观察；精确的依赖约束或锁；解析器的版本、决定、警告和文件哈希；独立的删除、发布权限、漏洞或事故证据；以及独立的部署清单。敏感名称可以保护，但连接关系必须有证据。

来源

  1. PyPI Docs — Yanking
  2. PEP 592
  3. PyPI Docs — Storage Limits
  4. PyPI Docs — JSON API