Кратко

  • PyPI называет yank недеструктивной альтернативой удалению.
  • data-yanked из PEP 592 обратим и не является журналом фактического выбора установщика.
  • Наблюдение индекса, ограничение, разрешение, файл и эксплуатация требуют разных записей.

Слово «отозванный» звучит окончательно. Документация PyPI говорит уже: мейнтейнер может рассмотреть yank для сломанного, неустанавливаемого, несовместимого или уязвимого релиза. Это не означает, что сам флаг доказывает любую из причин. Необязательное пояснение может помочь потребителю, но не заменяет расследование или общий вывод о безопасности.

Текущий управляющий жест PyPI относится к целому release. PEP 592 задаёт data-yanked на ссылках Simple API, так что клиент видит признак на уровне файлов. Связь этих поверхностей не создаёт квитанции об удалении, решения о праве публикации или доказательства загрузки на конкретную машину. yanked и yanked_reason в JSON API остаются наблюдениями индекса.

Решение резолвера — отдельный факт. PEP 592 требует игнорировать yanked варианты, если ограничение удовлетворяет не yanked вариант, и допускает отказ даже при отсутствии альтернативы. Точный pin, lock, политика клиента, время и видимый индекс меняют результат. Нынешний флаг не восстанавливает прошлое разрешение зависимостей.

Удаление также не равно yank. PyPI указывает, что yank не освобождает место; удаление без вмешательства администратора может быть необратимым и ломать закреплённые зависимости. Наличие файла не означает одобрения, а yank не означает исчезновение повсюду. Он не доказывает загрузку, выполнение или вред.

Daniel Kade предлагает хранить пять связей: датированное наблюдение проекта/релиза; точное ограничение или lock; версию, выбор, предупреждение и hash резолвера; отдельные доказательства удаления, полномочий или уязвимости; отдельный инвентарь развёртывания. Связь между ними нельзя додумывать.

Источники

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