Resumo

  • O PyPI apresenta o yank como alternativa não destrutiva à exclusão.
  • O marcador de PEP 592 pode ser removido e recolocado; ele não registra uma escolha concreta de instalador.
  • Estado do índice, restrição, resolução, artefato e implantação exigem evidências separadas.

“Retirada” parece uma conclusão completa. A documentação do PyPI é mais delimitada: uma versão quebrada, não instalável, incompatível com sua própria promessa ou vulnerável pode levar um mantenedor a considerar o yank. Isso não torna a marca uma prova de qualquer dessas causas. Uma razão informada ajuda o consumidor, mas não equivale a laudo de incidente ou julgamento de segurança.

No gerenciamento atual do PyPI, o yank é feito para um release inteiro. PEP 592 expõe data-yanked nos links da Simple API, portanto clientes podem observar o estado em arquivos. A conexão entre ação e representação não cria comprovante de exclusão, decisão sobre autoridade de publicação ou prova de que uma máquina baixou o artefato.

A escolha do cliente é outro fato. PEP 592 manda ignorar alternativas yanked quando uma não yanked satisfaz a restrição e permite recusar uma alternativa yanked mesmo sem outra solução. Pin exato, lock, política do resolvedor, horário e visão do índice importam. A marca atual não reconstrói uma resolução anterior.

Excluir também não é yank. O PyPI diz que yank não libera armazenamento; exclusão é permanente sem intervenção administrativa e pode romper usos fixados. Arquivo ainda disponível não é endosso; versão yanked não é sumiço universal. Os campos JSON yanked e yanked_reason descrevem o índice, não download, execução ou efeito.

O recibo proposto por Daniel Kade guarda: observação datada de projeto/versão; requisito ou lock; versão e decisão do resolvedor, avisos e hashes; evidência distinta de exclusão, autoridade ou vulnerabilidade; e inventário de implantação. A junção precisa ser demonstrada.

Fontes

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