Draft release feature on main archive to allow testing a release before it goes live
See original GitHub issueAs per this discussion thread:
https://mail.python.org/pipermail/distutils-sig/2015-October/thread.html#27234
it would be very nice if there where better ergonomics around package uploads – in particular some way to upload a new release, and then take a look over it to double-check that everything is correct before you – as a second step – hit the button to make it “go live”. Glyph suggests that in particular he’d like to be able to actually run a test install against the uploaded data as an end-to-end test:
https://mail.python.org/pipermail/distutils-sig/2015-October/027259.html
which indeed sounds glorious, and I think the super-slick way to do this would be to provide a unique private index URL which gives a view of what pypi would look like after your release goes live, and could be used like
pip install --index-url https://pypi.python.org/tmp/SOMEPKG/acd1538afe267/ SOMEPKG
(https://mail.python.org/pipermail/distutils-sig/2015-October/027263.html)
The idea would be basically that any request to /tmp/SOMEPKG/acd1538afe267/WHATEVER would return the same thing as a request to /WHATEVER, except for requests that would be affected by the addition of the new release, would act as if the release had already been made.
The use of a unique URL for each trial upload means that this still plays nicely with caching/CDNs. The inclusion of the package name in the tmp URL allows people to double-check that if they see a URL like this, then they know that the files there were actually uploaded by someone who is trusted to upload that package. You’d want to expire them after some short-but-reasonable time (a few days?) to prevent them being abused as private indices by unscrupulous people, and also just for general hygiene, but that’s fine.
Obviously this is very much a post-“become PyPI” wishlist priority request.
Issue Analytics
- State:
- Created 8 years ago
- Reactions:11
- Comments:62 (48 by maintainers)
At the PyPA minisummit in early May (at PyCon North America), we discussed the desire to increase pip’s and PyPI’s strictness with regard to metadata. Part of that progress will require staged releases – a temporary state that a release can be in where PyPI has it but hasn’t published it yet. This will let project owners/maintainers review where their fresh releases are out of compliance, and help us provide soft warnings during the intermediate period where we’re warning maintainers/owners about failing strictness checks but not yet blocking releases on those new stricter checks. I think of this state/feature as “package preview”.
We’ll need database support for understanding the release state (“is this published or not”).
As I understand it, this is a feature we want and are soliciting help to implement.
Not sure what argument you’re trying to make here 😃. No-one’s saying that we need this feature to prevent the end of the world – obviously we’ve survived this long without it. But that doesn’t mean it wouldn’t be nice to have? Wouldn’t you rather not have frustrated those people in your twitter mentions, if you had the option?