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

Michael Foord fuzzyman at voidspace.org.uk
Sat Feb 27 11:52:45 PST 2010


On 27/02/2010 19:48, C. Titus Brown wrote:
> On Sat, Feb 27, 2010 at 07:37:54PM +0000, Michael Foord wrote:
>    
>> On 27/02/2010 19:32, C. Titus Brown wrote:
>>      
>>> So where our goals differ is that you want to define a new convention
>>> going forward (2.7+, 3.3+) and I want to document some convention that's
>>> "good enough"&   backwards compatible to 2.4.
>>>        
>> I will strongly argue, and suspect Tarek will agree, that the
>> recommended practise for Python 2.4+ users is to use distutils2. That
>> way they can use the conventions that will just-work (tm) in future
>> versions of Python. distutils2 and unittest2 are both maintaining
>> compatibility with Python 2.4 specifically so they can be used in this
>> way.
>>      
> Humm, why isn't this style of test running:
>
>    % python -m somepackage.tests.run
>
> a good solution that removes the need for using distutils2 for 2.4+ users?
>
>    

Because there are all sorts of good changes to packaging coming in 
distutils2 for users of Python 2.4+ (kind of the point of it existing), 
a standard test command being just one of them.

> We should put something in the Hitchhiker's Guide to Packaging, which is
> for 2.4+.  So far Tarek has avoided putting in "just use distutils2";
Because the guide was started a while back and distutils2 only sprang 
into existence after the language summit.

>   I doubt
> that's going to change because the testing community wants it to, and I
> think it'd be a bad idea anyway.
>    

It won't just be for testing, all the 
new-goodness-packaging-infrastructure is going to depend on distutils2.

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.





More information about the testing-in-python mailing list