Repository navigation
Conversation
…API changes to use staged releases
|
All commit authors signed the Contributor License Agreement. |
Documentation build overview
177 files changed ·
|
hugovk
changed the title
hugovk
changed the title
warsaw
left a comment
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
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
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
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.
|
|
||
| A session's creation path is fixed when it is created, and the two paths **MUST NOT** be mixed. | ||
| If a non-terminal session already exists for a name-version pair (see :ref:`publishing-session-multiple`), a request to | ||
| contribute to it through the *other* path **MUST** be rejected with a ``409 Conflict``: any legacy upload for |
There was a problem hiding this comment.
did a survey of existing upload clients and a 409 would trigger handling for "already exists" semantics due to another project, pypiserver
within the legacy endpoint it would be safer (for PyPI at least) to retain a generic 400 with a message that does not contain any of the magic strings from these clients in the message 🙃
There was a problem hiding this comment.
I can move this to a generic 400 given that PEP 847 has not been pronounced, I think a 409 will make more sense once PEP 847 is pronounced and tools start to account for it where problem details can make it more clear about what kind of conflict it is.
There was a problem hiding this comment.
I think we can leave it as a 400 for the legacy endpoint and leave any PEP847/RFC9457 explicitly to the new upload 2.0 endpoints.
Even once that PEP lands and is implemented, it is unlikely to help for clients of the legacy endpoint.
ewdurbin
left a comment
ewdurbin
left a comment
There was a problem hiding this comment.
pending one concern with 409 vs 400, and one non-blocking editorial suggestion, i approve.
i also nudged @miketheman to take a look as previously requested.
Co-authored-by: Ee Durbin <ewdurbin@gmail.com>
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.