Repository navigation
Conversation
…API changes to use staged releases
|
All commit authors signed the Contributor License Agreement. |
Documentation build overview
156 files changed ·
|
warsaw
left a comment
There was a problem hiding this comment.
This is a great addition to the PEP. I have some comments for a few things that need clarification, but otherwise +1. And welcome aboard as a co-author!
warsaw
left a comment
There was a problem hiding this comment.
I really like this addition to the PEP. It provides a fantastic transition period from legacy to upload-2.0. I have a few questions and suggestions.
…etween legacy and 2.0, minor fixes for other sections.
warsaw
left a comment
There was a problem hiding this comment.
I like the state of this PR. I have a few open questions, but I think we're getting very close. I'd really like @miketheman to weigh in from his perspective on PyPI, and the other PEP authors and delegate to get a chance to comment as well.
| @@ -336,9 +354,14 @@ interpretation to aid in diagnosing underlying issue. | |||
| Some responses may return more specific HTTP status codes as described in the text below. | |||
There was a problem hiding this comment.
Note to self. Once PEP 847 is approved, we should update this PEP to specifically reference it. @woodruffw @dstufft
|
|
||
| A legacy client that is unaware of this PEP cannot issue a :ref:`publish request | ||
| <publishing-session-completion>`. Where an index has created a session on such a client's behalf, and the | ||
| session is subject only to automated processing, the index **MAY** publish the session itself once that |
There was a problem hiding this comment.
In the scenario where an index uses sessions by policy of the index/project, it seems this leaves clients who do not support the new protocol in bit of a lurch, unable to control when their staged files enter the processing state which may be before they want, or long after.
I assume there is some desire for this to eventually be the default on PyPI to provide a mechanism for pre-publication malware scanning, so I think it is a bit unwieldy to not have a story around how we will handle users of legacy clients who may never adopt explicit session support.
If I'm honest, I would prefer that we move very quickly to rollout Upload 2.0, and then very quickly to deprecate the legacy endpoint, as active uploaders are the some of the most easily "reached" clients we have. When their publication flows break, they are much more likely to be actively ready to repair them.
I'm a bit concerned that having the interop period, with itself potentially being divided between "opt-in" and "by policy" staging, creating more than one distinct migration/adoption period.
There was a problem hiding this comment.
I tend to agree I would definitely like the rollout of Upload 2.0 and deprecation of the legacy endpoint to be quick in succession. I think otherwise places a lot of burden on maintenance and as you stated it can create more than one adoption period. And speaking from JOB1 experience the longer that a migration is allowed to take the longer that the long tail becomes.
…enial of service by having scanning wait until all file uploads complete.
Amendments based on DPO discussion https://discuss.python.org/t/pre-pep-staged-releases-separated-from-pep-694/107804/59
@warsaw - here are my proprosed amendments which I would like your sign off on as well.