Add semantics for drafts#2
Conversation
| the server wishes to communicate to the end user that are not specific to any | ||
| one file. | ||
|
|
||
| The ``url`` key represents a unique and absolute URL for the session. This is |
There was a problem hiding this comment.
Is this different than the url in the Location header?
There was a problem hiding this comment.
I missed that! I don't think so, seems like we can remove this.
| ~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| In order to determine which draft sessions the server is aware of and are | ||
| pending publication, servers **MUST** support enumerating draft sessions. When |
There was a problem hiding this comment.
Why do we need to support enumeration? If you've already gotten a session, can't you just use the URL you've already received?
There was a problem hiding this comment.
I'm imagining a release process like the one used for pyca/cryptography, where they build and upload from multiple different environments (to get platform/architecture coverage). This means that a specific build environment doesn't have a priori knowledge of other related upload sessions, but you still want a way to collect all the artifacts for a given release (with multiple upload sessions) maybe run some tests or something, and then request that the sessions are all published simultaneously (which this doesn't necessarily account for since they'd have to make 1 request per upload session, but I'm assuming we'd provide the same session url for the same name+version, so it would be 1 request for PyPI)
I'm also imagining a workflow where a user iterating on multiple candidate artifacts for a given release via drafts, and doesn't have a great way to persist the upload session url between attempts (like maybe they're running twine upload --draft multiple times). And since we're saying the URL is not predictable and can change, we'd need a way to determine which sessions are available to publish when they run twine publish or whatever
|
Seems like this is unnecessary now that the PEP has been modified to include support for publishing drafts. |
2 participants
This attempts to keep the URL structure clean by reusing the root to list draft sessions and including per-session URLs. The only thing I'm not totally sure about is the empty
POSTto publish a draft session, but happy to take edits anywhere.