Skip to content

Support yanking files and yanking releases #13755

@notatallshaw

Description

@notatallshaw

Yanking, as defined by PEP 592 has two separate concepts:

  • Yanking individual files
  • Yanking entire releases

It does not define what a yanked release means, but for pip's purpose I think a reasonable definition is:

All installable artifacts for that version are yanked

Currently pip does not have a clear distinction between yanking files or yanking releases, but I think it should be the following:

  1. If an individual file is yanked, but not the whole release, that file must not be selected unless the explicit URL is given (e.g. as the only URL available for a release when installing from a lock file), but other files from that release may be selected
  2. If a release is yanked then we should consider that "version" yanked and follow version specifier behavior where it can only be selected if that version is explicitly pinned, e.g. ==1.0.

It might make sense to implement the latter behavior directly in packaging because you end up with edge case situations like having the specifier >1 and a yanked release 2.0 and a pre-release 3.0rc1, in this case 3.0rc1 should be selected but currently isn't by pip.

Either way we need tests to cover both the scenarios of yanking individual files (distributions), and yanking entire releases, and make sure we are handling them on the correct level. I am not currently working on this, but unless anyone else wants to drive this I have it on my to do list.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions