When we locked down pypi to prevent uploading an sdist to overwrite a previous I remember that some people wanted a brief window to check for brown paper bag issues and be able to upload a new tarball in that window if needed. IIRC, those people were told to use testpypi for that sort of thing. Upload potential tarball to testpypi. If it works, go ahead and rerun to upload to the real pypi. If it doesn't, fix it and try again. This past week I decided to try out that workflow for a project that I'm managing the releases for and ran into a snag. testpypi has the same behaviour as production pypi wherein you can only upload a given sdist once and afterwards it's no longer allowed. For the use case above this is problematic. It essentially changes the idea of "test your release on testpypi before making a release" into "You can have to chances to get it right if you use testpypi" which, although better than uploading directly to pypi, still leaves a lot of room for error (let's face it: I know that if I'm stuck releasing late at night due to time constraints and make a mistake, chances are better than normal that my fix won't be the perfection that my ordinary code is and could have other showstopper bugs that I'd want my testing to catch as well ;-) Is this something that we could change for testpypi? It could be implemented in many ways: straight overwrite, being able to destroy a version so that it seems to never have existed, or being able to destroy and recreate a package so that it has no uploaded sdists recorded. On the other side of the usefulness of enabling the testing use case above, such a change would be a difference between testpypi and production pypi meaning that it would no longer be testing exactly the same functionality as will be deployed in production. I'm not sure if that's a more important consideration or not. I figured that unless I asked, I would never know the answer :-) Thanks, -Toshio