> On Oct 30, 2017, at 1:41 PM, Toshio Kuratomi <a.bad...@gmail.com> wrote:
>
> I figured that unless I
> asked, I would never know the answer :-)
>
TestPyPI has a couple of use cases, and it’s not very good at any of them.
One use case is to serve as a staging site for production PyPI to test changes
before they go to live. If I had to pick any use case as it’s “core” use case,
it would be this one, it’s currently optimized for it and we’re unlikely to
make changes that deviate from it. Unfortunately it’s not really good at this
because staging sites are generally not a great way to prevent regression
(versus something like automated testing), so with Warehouse TestPyPI is no
longer a staging site for the production code, and they are deployed at the
same time.
Another use case is the one you specified, someone wants to test their releases
prior to uploading to the “real” PyPI. TestPyPI is not great at this use case
both because, as you noted, it has the same “you can only upload a file once”
semantics as PyPI does, but also because it doesn’t have a full copy of
everything on PyPI (and worse, it potentially has broken or insecure or
malicious versions of your dependencies) so pip might either be blatantly
broken OR produce subtly broken installs. Long term the solution that I believe
has merit for this, is the ability to, on regular PyPI, “stage” an upload to a
temporary location that would automatically be deleted after some period of
time, and that once you were satisfied with it, could be published/committed
and thus be available to normal ``pip install`` invocations. This not only
would allow testing a release beforehand, but it would also allow projects that
produce many different artifacts across a variety of platforms to collect them
all and upload them and make them all available immediately instead of one at a
time. You can see more about this idea/use case at
https://github.com/pypa/warehouse/issues/726
<https://github.com/pypa/warehouse/issues/726>.
The third relevant use case of PyPI is people simply messing around or doing
testing of a generalized workflow tool but not specific to a specific package.
This could also include people who are learning how to produce a package, but
using a trivial throw away project (the infamous printer of nested lists is an
example of this). TestPyPI can be used for this as well, but again it’s not
really good at it. The key difference here is that ideally these projects are
either ephemeral or namespaced to the specific user. I don’t have a great idea
for how best to handle this, the immediate thought is a secondary deployment of
Warehouse (such as what TestPyPI is now), that just periodically and
automatically purges any projects > N days old to give it a more of a “sandbox”
vibe and use case. Given the aforementioned staging feature, we would likely
otherwise keep the same ruleset as exists on the production PyPI (and ideally,
we’d be re-using credentials too, instead of it literally being a complete
secondary deployment). That idea isn’t set in stone and I haven’t done a lot of
thinking about it yet, but discussion of that particular use case and ideas to
fix it would take place in https://github.com/pypa/warehouse/issues/2286
<https://github.com/pypa/warehouse/issues/2286>.
So longer term, I hope to shut down TestPyPI and replace it with features
and/or deployments more suited to whatever specific task/use case we’re hoping
to have served by it, rather than just sort of being poor at everything.
- dstufft
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
