TestPyPI can be useful for those who are not package maintainers, but want to learn about Python Packaging and need a 'playground' to experiment with it.
Mariatta Wijaya On Mon, Oct 30, 2017 at 10:41 AM, Toshio Kuratomi <a.bad...@gmail.com> wrote: > 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 > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
