Enable a "Test" mode that allows package reuploads

[dstufft]

Test PyPI is designed to be able to test packages, it should be treated as a sandbox and people shouldn't be "punished" for using it as such. We'll need some way to allow package reuploads in Test PyPI (but not in regular PyPI).

[theherk]

I think it could be valuable to lock packages in test that are registered in the production pypi, so that the package maintainer can continue to test without issue. But until it is locked in production, it should be able to be freely deleted and recreated in test.

[dstufft]

Honestly, I don't have a problem just freely allowing reuploads/deletions in test. The only catch is we'll need to restructure the URLs a bit to handle it sanely, but that's something I wanted to do anyways. The main reasons to lock packages on the "real" PyPI don't really apply to test at all once we restructure the URLs.

[domibarton]

First of all, I really appreciate your work! The Python community (and therefor you guys) is pretty awesome, I love it :)

I already suggested the same thing here, but apparently you already know about this issue. I like the fact that packages uploaded on the live repo are locked. It will result in a more "secure", consistent, reliable and clean repo. It's great that an existing version can no longer be replaced by the developer and therefor data integrity is enforced. I suppose without this feature it can lead to a lot of confusion, if an active version will silently be replaced.

However, as you already wrote above, it would be great to get a sandbox without punishment as soon as possible. Especially for new users to test their their first package. I created my first PyPI package a few days ago and had to learn it the "hard way" ;)

Can I help and support you guys somehow? I want to give something back to the community and I especially want the get more active in the Python community. Let me know if I can support you guys in any way!

Thanks guys!

[ncoghlan]

@domibarton Sorry for the lack of response here! We unfortunately haven't been particular good in the past couple of years when it comes to harnessing the enthusiasm of folks that express interest in contributing :(

Some notes on possible design directions here:

• something users are interested in is knowing whether the projects they use might have existing releases "unpublished", or have new artifacts (such as wheel files) added
• as maintainers, we're not interested in forcing existing publishers to change the way they manage their releases. Since many publishers and their users are happy with the current "immediate publication" model, we're going to continue supporting it
• however, we'd like to offer a potentially smoother "Stage releases prior to publication" model, which allows folks to prepare the full artifact set for a release in a staging index, and then have a single "Publish Release" operation that moves the entire staged release into the main index as a coherent unit, rather than as individually uploaded files
• as an opt-in mechanism, the staged release model could have additional publisher constraints associated with it. Specifically, it would at least prohibit adding any new artifacts to previous releases, and it could potentially even prohibit unpublishing old releases without contacting the PyPI administrators.
• the information on whether or not a particular release has been locked against future changes would be made available as part of the index server's project metadata API, allowing users and tools to make informed decisions about their dependency pinning
• we would also consider whether or not to make the staged release model the default for new projects, since it's far more user friendly when it comes to testing your artifacts prior to publishing them

At a technical level, the key capability that Warehouse would need in order to support this is the ability to publish two separate indices: the regular index that it already publishes, and a separate staging index for not-yet-published staging releases.

It would also need to model (and make available via a metadata API) the distinction between the somewhat mutable immediately published releases (i.e. unpublishing and addition of binary artifacts permitted), completely mutable staging releases, and completely locked published releases.

The upload API would also need to be adjusted such that it handled the 3 kinds of release state differently.