要約

  • PyPI は yank を削除しない代替手段として説明している。
  • PEP 592 の data-yanked は取り消し、再設定でき、実際の導入履歴ではない。
  • 索引の表示、要求条件、解決結果、取得物、運用状態を一つの記録に混ぜない。

「yank」という語は、全面的な撤回を連想させる。PyPI の説明はそこまで進まない。壊れている、導入できない、互換性の約束に反する、脆弱性を含む、といった場合にメンテナーが検討できる選択肢である。記入可能な理由は下流の判断を助けるが、事故の調査結果でも、すべての利用者への安全判定でもない。

現在の PyPI 管理画面では release 全体を yank する。PEP 592 は一方で Simple API のリンクに data-yanked を定める。従って、管理上の行為とクライアントがファイル単位で観測する表示は関係していても、削除の受領証、公開者の権限判断、特定端末への導入記録にはならない。JSON API の yanked と yanked_reason も索引の観測値である。

選択の事実は別に残る。PEP 592 は、未 yanked の候補が制約を満たすなら yanked 候補を無視するよう求め、候補がなくても拒否する実装を許す。固定された正確な版、lock、クライアントの方針、観測時刻、見えていた索引が結果を変える。現在のフラグだけから、以前の解決器が何を選んだかは分からない。

削除も別の状態である。PyPI は yank では保存容量が減らず、削除は管理者の介入なしには戻せず、固定版に依存する利用者を壊し得ると説明する。ファイルが残ることは承認ではなく、yank があることは全世界で利用不能という意味でもない。

Daniel Kade は、日時付きの索引観測、要求条件または lock、解決器の版・選択・警告・hash、別建ての削除・権限・脆弱性の証拠、そして導入台帳を結ぶ五部の記録を勧める。結び付けは推測でなく証拠によるべきである。

情報源

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