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

[Michael Foord]

On 27/02/2010 19:58, C. Titus Brown wrote:
> On Sat, Feb 27, 2010 at 07:52:45PM +0000, Michael Foord wrote:
>    
>> 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.
>>      
> ...for setup.py alone, which we are discussing in the other e-mail thread ;)
>
>    

Well, for all the infrastructure that distutils provides yes. My guess 
(an assumption - see below) is that once distutils2 reaches maturity the 
packaging guide will start with something along the lines of "If you 
have Python 2.4-2.6, first install distutils2".

>>> 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.
>>      
> Hrrm, I guess we could just ask Tarek.  There have been substantial revisions
> to the HGTP since that decision, which include this text,
>
> http://guide.python-distribute.org/introduction.html#current-state-of-packaging
>
> """
> The distutils module provides the basics for packaging Python. Unfortunately,
> the distutils module is riddled with problems, which is why a small group of
> python developers are working on distutils2. However, until distutils2 is
> complete it is recommended that the Developer either use pure distutils or the
> Distribute package for packaging Python software.
> """
>
> It's unclear to me if this means "please use distutils2, when it's complete,
> for packaging in 2.4+" or if it means "once distutils2 is in the standard
> library, please use that over distutils."
>    

Right. I suspect the former, but we will need to check with Tarek. I 
doubt he would bother making distutils2 compatible with Python 2.4 if he 
didn't intend people to use it though...

Michael

> cheers,
> --titus
>    


-- 
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.