[Distutils] What's the use case of testpypi?

[Nick Coghlan]

On 31 October 2017 at 23:53, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 31 October 2017 at 22:49, Jeremy Stanley <fungi at yuggoth.org> wrote:
>
>> On 2017-10-31 16:25:08 +1000 (+1000), Nick Coghlan wrote:
>> > 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?
>> [...]
>>
>> Do the two share enough common code for successful uploading to a
>> devpi instance to be indicative of whether PyPI will accept or
>> reject on the grounds of, e.g., invalid trove classifiers (this one
>> in particular has been the most common preventable but otherwise
>> untestable upload failure our community encounters).
>>
>
> Even if they don't currently, that's likely an easier problem to fix than
> working out how to intermingle devpi's "pre-release developer sandbox" user
> experience with PyPI's "authoritative release publishing platform" user
> experience in one service, especially since the Legacy PyPI -> Warehouse
> migration is already encouraging several of those validation features to be
> extracted out to helper libraries.
>

Taking the classifiers list as a specific example: while that's *currently*
stored in the live PyPI database, there isn't anything in particular that
says that that needs to be the authoritative source of the list - it could
be redefined as a cache of a list that PyPI picks up from somewhere else.

It could, for example, be moved into a static data file in the `packaging`
project, and have updates be deployed to the live service by way of new
releases of that project. Tools could then decide for themselves whether to
depend on the static list in the packaging project, or query PyPI to get
the list for whichever version of the library PyPI itself was using.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171101/bad38549/attachment-0001.html>