[TIP] Guidelines for where to put tests & how to package them

[Michael Foord]

On 27/02/2010 19:22, C. Titus Brown wrote:
> [snip...]
>> but I was talking about setuptools and the precision was mainly for
>> the loader that performs discovery and features in setuptools 0.7.x
>> trunk, I really don't follow `distribute`, so ... (besides PJE has
>> always had the virtue -at least according to my experience ;o)- of
>> providing the right comment at the right time, thus saving me from
>> chaos ;o)
>>      
> Be that as it may, we're doing our best to convert this whole thing into either
> a PEP-driven process or at least a documented good-enough practice.  PJE is
> welcome to participate in both!
>
> I *really* want to present Tarek and the distutils folk with a sensible,
> minimalistic convention that doesn't break anything (and could even be
> compatible with most things that are out there).  Then  PJE can update
> setuptools to do the Right Things, distutils2 can handle it, etc.
>    

 From what you are proposing you would like distutils2 to default to 
'package.test.run' for the "setup.py test" command. Presumably if 
multiple packages are specified then you want ["package1.test.run", 
"package1.subpackage.test.run", "package2.test.run"], with the exception 
that we don't look for 'test.run' in sub-packages that are called 'test' 
(because that would be silly).

I've discussed the standard library convention I prefer, which *doesn't* 
require a naming convention. However Tarek may (or may not) like your 
convention so I will leave that to him.

>    
>>>> BTW, I am strongly -1 for using the discovery protocol introduced in
>>>> 2.7 (AFAICR), specially because it collides with test_suite
>>>>          
>>> You'd rather not use a unittest supported protocol because it clashes with
>>> an unsupported protocol?
>>>        
> I agree with Olemis here -- let's try not to actively break setuptools unless
> there's a good reason.  It's very widely deployed and large parts of it are
> serving as the basis for distutils2, from what I understand.
>
>    
Olemis was confused as to what setuptools did - it does not support a 
callable for the test_suite argument.

I would prefer 'tests' for the new distutils "setup.py test" command, 
but we could support the setuptools argument as a deprecated variant of 
that. If a package uses setuptools for its setup.py then it will 
continue to work *anyway*, so perhaps that isn't necessary.


Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.