Add support for yanked releases and files (PEP-592)

[radoering]

Pull Request Check List

Resolves: #2453

Requires a poetry-core version with python-poetry/poetry-core#400

• Added tests for changed code.
• Updated documentation for changed code.

[dimbleby]

A recent example of the desirability of understanding the yanked flag: the most recent version of cryptography that is currently available is 37.0.3 - and it is yanked "due to a regression in OpenSSL that was producing heap corruption".

cryptography will appear in a lot of dependency trees, as of right now poetry will be locking to that yanked version.

[mkniewallner]

Tested locally against PyPI repository (didn't test other repositories), it works as expected.

As possible follow-ups improvements (in future PRs):

• Maybe we could reflect the "yanked" information when using poetry show?
• Would a strict flag on the different commands (install, lock --check, etc.) or a global configuration that prevents installation/produces failure whenever a yanked dependency is used be something that users want? The warning is clearly noticeable locally, but on a CI, it may be suitable to ensure that no yanked dependency is used when installing dependencies, or when checking that the lock file is up-to-date.

[mkniewallner]

Clearly outside the scope of this PR, but I wonder if PyPI lets you upload a new file on a yanked release, and if so, if this sets yanked / yanked_reason attributes accordingly.

It's a bit sad that we have to assume that a random file that is yanked means that the entire release is yanked, just because of a limitation from the structure of the API, especially since the releases don't seem to be ordered by upload_time:

$ curl -s https://pypi.org/pypi/cryptography/json | jq '.releases["37.0.3"][].upload_time'
"2022-06-21T19:07:43"
"2022-06-21T19:07:48"
"2022-06-21T19:08:26"
"2022-06-21T19:09:32"
"2022-06-21T19:09:38"
"2022-06-21T19:08:32"
"2022-06-21T19:08:03"
"2022-06-21T19:09:44"
"2022-06-21T19:08:55"
"2022-06-21T19:08:59"
"2022-06-21T19:09:04"
"2022-06-21T19:08:40"
"2022-06-21T19:08:10"
"2022-06-21T19:07:52"
"2022-06-21T19:08:45"
"2022-06-21T19:08:15"
"2022-06-21T19:09:08"
"2022-06-21T19:07:57"
"2022-06-21T19:08:49"
"2022-06-21T19:08:20"
"2022-06-21T19:09:11"
"2022-06-21T19:07:26"

[radoering]

Good question. For now I'd just rely on the PEP which says:

In Warehouse, the user experience will be implemented in terms of yanking or unyanking an entire release, rather than as an operation on individual files, which will then be exposed via the API as individual files being yanked.

[radoering]

As possible follow-ups improvements (in future PRs):

Both sound reasonable.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.