Conversation
…API changes to use staged releases
|
All commit authors signed the Contributor License Agreement. |
Documentation build overview
156 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
| resolves to ``error``, the session remains editable and the reason is reported in the session's ``notices``, | ||
| as described in :ref:`publishing-session-states`. | ||
|
|
||
| The ``processing`` state **MAY** be used to run asynchronous review of a session's files before it is |
There was a problem hiding this comment.
Is the intention that an index may perform similar asynchronous review per file as well or do we only expect such review to occur once a user requests publication of the entire release?
The processing state for file uploads (initiated by the caller submitting to the completion endpoint) was kind of where I had this processing occurring in my head. With more thought towards this PR, I think that there's a good argument for per-file and per-release processing, although I think I ultimately like gating on the results being part of the publication step.
An index may have an adverse result based on reviews around malware for a given file that is only exposed once publication is attempted, but any processing as it relates to correctness (file size, checksum, metadata, compatibility, etc...) is probably best raised immediately in the file session and treated as non-recoverable as it is currently written.
This is mostly me talking it out, but the question I think I'm raising now is:
Do we want to have a similar callout for what kinds of results are raised in the file-upload-session completion versus the release publication step?
There was a problem hiding this comment.
That is a good call out, I should definitely add something around what kinds of result are raised in the different steps.
I think in terms of the malware types of scans those definitely have to be per file just given that iirc there is a 14 day window for file uploads to a given version as of now. Since the primary goal of this type of scanning is to eliminate as many supply chain attacks as possible.
| return the :ref:`publishing session creation response body <publishing-session-response>` from that upload, | ||
| including the ``links`` and ``session-token`` keys, so that the publisher can then use the endpoints in this | ||
| PEP to :ref:`preview <staged-preview>`, :ref:`publish <publishing-session-completion>`, or :ref:`cancel | ||
| <publishing-session-cancellation>` the session. An index **MAY** also create a session for an upload based on |
There was a problem hiding this comment.
One concern here: Indexes which return the new publishing session creation response body to a client that does not understand it may end up in situations where the client then logs that response body to their logs (I'm thinking in public CI).
I don't think these need to be treated as strictly sensitive as the expectation of a tool that does not know what to do with the result is that the file is immediately visible on PyPI, but I wanted to flag it.
|
|
||
| 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.
This branch has not been deployed
3 participants
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.