[Distutils] Updated drafts of metadata 2.0 (PEP 426 and PEP 440)

[Daniel Holth]

On Thu, Jun 20, 2013 at 4:19 PM, holger krekel <holger at merlinux.eu> wrote:
> On Fri, Jun 21, 2013 at 01:05 +1000, Nick Coghlan wrote:
>> On 21 Jun 2013 00:36, "holger krekel" <holger at merlinux.eu> wrote:
>> >
>> >
>> > I still think the testing part of "the interchange format
>> > between software publication and integration tools" is underspecified.
>> > The dependencies alone will not be sufficient to allow the running
>> > of tests in many cases.  Or am i missing something?
>>
>> If "setup.py test" works for a distribution today, it will still work under
>> PEP 426. Anything more is deliberately deferred (as noted in the PEP).
>
> I am a little confused.  Early in the PEP you say:
>
>     The published metadata for distributions SHOULD allow integrators,
>     with the aid of build and integration tools, to:
>
>     ...
>     * if supported by the distribution, run the distribution's automatic
>       test suite on an installed instance of the distribution
>
> but a few sentences later:
>
>     The current iteration of the metadata relies on the distutils
>     commands system to support other necessary integration and
>     deployment activities:
>
>     ...
>     python setup.py test: run the distribution's test suite on a built
>     (but not yet installed) distribution
>
> And i am not sure what exactly PEP426 defines wrt to testing now.
> I saw the "test_requires" and "test_may_requires" fields and thought
> they were part of an idea already how to configure running of tests.
> But is there anything more in the current PEP426 that i missed?
>
> To help with my confusion, could you maybe describe how "python setup.py
> test" is to interoperate (if at all) with the new metadata format as is?
>
> thanks,
> holger

"python setup.py test" does not change at all as a result of this work.

The only interoperability that will happen is that an external test
runner will better be able to ask an installer to install those
dependencies before attempting to run the test, since
installs-as-side-effects-of-setup.py are not so great.

Later setup.py will be replaceable, and /that/ specification will
define a standard entry point for testing. These metadata PEPs are
mostly about the installer, database of installed files, and package
indexes.