Repository navigation
Conversation
…API changes to use staged releases
Documentation build overview
177 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.
There was a problem hiding this comment.
I'd definitely like to agree on a quicker migration to Upload 2.0, but I don't know how well that will work in practice. There will probably be a very long tail of old clients that are difficult to upgrade. How willing are we to break them? That said, those users can always issue a curl or other raw-HTTP comment for the final publish, and we could create a very simple client for the control plane.
…enial of service by having scanning wait until all file uploads complete.
warsaw
left a comment
There was a problem hiding this comment.
I approve this, but think we need approval from at least one other PEP author to merge.
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.