On 31 October 2017 at 03:41, Toshio Kuratomi <a.badger@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.

Ideally we'd be recommending https://devpi.net/docs/devpi/devpi/stable/%2Bd/index.html to folks looking to develop a robust pre-release artifact testing workflow.

While we mention it a couple of times on packaging.python.org [1,2], and include it in the packaging related Non-PyPA Projects list [3], we don't really emphasise that it makes a much better platform for pre-release testing and private experimentation than PyPI itself does (see https://devpi.net/ for an example of a deployed instance with multiple distinct user namespaces).

Given Donald's comment about the current test PyPI not being particularly good at any of its roles, perhaps it would make sense to aim to replace it with a periodically purged DevPi instance?

Cheers,

Nick.

[1] https://packaging.python.org/guides/index-mirrors-and-caches/?highlight=devpi#caching-with-devpi

[2] https://packaging.python.org/guides/hosting-your-own-index/?highlight=devpi

[3] https://packaging.python.org/key_projects/?highlight=devpi#non-pypa-projects