[Distutils] Patch for your setuptools issue

[Michael Foord]

Tarek Ziadé wrote:
> On Tue, Jun 2, 2009 at 12:58 PM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>   
>> This failure happens because in line 136(ish) of setuptools.command.test you
>> are calling unittest.main passing in testRunner=None.
>>
>> I don't think this is caused by changes to unittest itself and would have
>> failed with the previous versions. Perhaps changes in distutils or
>> setuptools?
>>     
>
> The test pass under 2.5, 2.6, so there must be something different in
> the environment
>   

If I run it with Python 2.6 I get the same problem ('python setup.py test').

It works fine under 2.5 for me though and testRunner is still None.

Ah - I see the problem. In Python 2.5 testRunner defaulted to None and 
main created its own TextTestRunner. In 2.6 the default was changed to 
be the TextTestRunner class. Unfortunately 2.5 needs either None or an 
instance of a runner.

The easiest thing to do might be to create a dictionary of keyword 
arguments and omit testRunner if it is None. Call main with 
unittest.main(**args).

Michael



>   
>> Happy to dig further into it if needed.
>>     
>
> Thanks for the help, I guess we need to dig into it deeper on our side
>
> Cheers
>
>   
>> Michael
>>
>>
>>
>> Tarek Ziadé wrote:
>>     
>>> On Tue, Jun 2, 2009 at 12:00 AM, P.J. Eby <pje at telecommunity.com> wrote:
>>>
>>>       
>>>> At 09:39 PM 6/1/2009 +0200, Tarek Ziadé wrote:
>>>>
>>>>         
>>>>> 2009/6/1 P.J. Eby <pje at telecommunity.com>:
>>>>>
>>>>>           
>>>>>> At 07:01 PM 6/1/2009 +0200, Tarek Ziadé wrote:
>>>>>>
>>>>>>             
>>>>>>> Antoine,
>>>>>>>
>>>>>>> here's a patch for your issue.
>>>>>>>
>>>>>>>               
>>>>>> Hm.  Did you send this patch before?  I don't recall seeing it.
>>>>>>
>>>>>>
>>>>>>             
>>>>> No, I have just created it. I can add it to setuptools issue tracker
>>>>> if you think it's useful
>>>>>
>>>>>           
>>>> The idea is useful; I think there might be another way to do it now that
>>>> you've given me the idea.  I'd prefer to do it in a way that doesn't copy
>>>> code, i.e., by having __getattr__ return something that makes the
>>>> distutils-level behavior the same as before, but not by copying the old
>>>> distutils code.  That having been said, this might be a good patch to go
>>>> in
>>>> the meantime.
>>>>
>>>>         
>>> I have pushed it here :  http://bugs.python.org/setuptools/issue76
>>>
>>> the tests pass using previous python interpreters,
>>>
>>> Although it fails with the current python trunk,
>>> it seems that unittest.main behaves differently. I am cc'ing  Michael
>>> for some insights because I think
>>> this has been changed lately.
>>>
>>>
>>> Traceback (most recent call last):
>>>  File "setup.py", line 95, in <module>
>>>    scripts = [],
>>>  File "/Volumes/MacDev/svn.python.org/python-trunk/Lib/distutils/core.py",
>>> line 149, in setup
>>>    dist.run_commands()
>>>  File "/Volumes/MacDev/svn.python.org/python-trunk/Lib/distutils/dist.py",
>>> line 926, in run_commands
>>>    self.run_command(cmd)
>>>  File "/Volumes/MacDev/svn.python.org/python-trunk/Lib/distutils/dist.py",
>>> line 945, in run_command
>>>    cmd_obj.run()
>>>  File
>>> "/Volumes/MacDev/svn.python.org/setuptools/setuptools/command/test.py",
>>> line 121, in run
>>>    self.with_project_on_sys_path(self.run_tests)
>>>  File
>>> "/Volumes/MacDev/svn.python.org/setuptools/setuptools/command/test.py",
>>> line 101, in with_project_on_sys_path
>>>    func()
>>>  File
>>> "/Volumes/MacDev/svn.python.org/setuptools/setuptools/command/test.py",
>>> line 134, in run_tests
>>>    unittest.main(
>>>  File "/Volumes/MacDev/svn.python.org/python-trunk/Lib/unittest.py",
>>> line 1662, in __init__
>>>    self.runTests()
>>>  File "/Volumes/MacDev/svn.python.org/python-trunk/Lib/unittest.py",
>>> line 1744, in runTests
>>>    self.result = testRunner.run(self.test)
>>> AttributeError: 'NoneType' object has no attribute 'run'
>>>
>>>
>>>
>>>
>>>       
>>>> I am thinking, btw, that it's time to retire the 0.6 stable branch and
>>>> begin
>>>> only doing new stuff on the trunk, anyway.
>>>>
>>>>         
>>> +1
>>>
>>> Maybe a final 0.6 release could be done, including the svn 1.6 patch
>>> (or a patch to make the last 0.6.x release not suffering from svn
>>> changes anymore
>>> e.g. by adding a plugin behaviour)
>>>
>>>       
>> --
>> http://www.ironpythoninaction.com/
>>
>>
>>     
>
>
>
>   


-- 
http://www.ironpythoninaction.com/