[PEAK] Re: setuptools test command generates exception after
interpreter shutdown
Nikolaus Rath
Nikolaus at rath.org
Mon May 3 23:00:58 EDT 2010
"P.J. Eby" <pje at telecommunity.com> writes:
> At 01:55 PM 5/3/2010 -0400, Nikolaus Rath wrote:
>>On 05/03/2010 01:20 PM, P.J. Eby wrote:
>> > At 07:04 PM 5/2/2010 -0400, Nikolaus Rath wrote:
>> >> Nikolaus Rath <Nikolaus at rath.org> writes:
>> >> > Hello,
>> >> >
>> >> > Consider this:
>> >> [...]
>> >>
>> >>
>> >> Note that this does not happen on every system. I reproduced this on
>> >> Ubuntu Intrepid with Python 2.6.2, but I was not able to reproduce it on
>> >> Ubuntu Lucid with Python 2.6.5. I can't tell if it's the Python version
>> >> or something else though.
>> >
>> > It's probably something else in your environment -- maybe in a
>> > sitecustomize.py, or a setuptools plugin that's installed in one
>> > environment but not the other?
>>
>>No, apparently not. It also happens with -S:
>>
>>$ python -S ./setup.py test
>
> Um, that won't necessarily affect plugins, depending on how they're
> installed. What's your full sys.path when the tests run? (on both
> the working and non-working machines)
Working:
$ python -S -c 'import sys; print sys.path'
['', '/usr/lib/python2.6/', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload'
Non-working:
$ python -S -c 'import sys; print sys.path'
['', '/usr/lib/python2.6/', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload']
I also found out something else: on the working machine, multiprocessing
is *not* loaded with my test case. But if I simply insert an 'import
multiprocessing' into the test case, the test fails on *both* machines
with the same error.
>> > The 'multiprocessing.util' module (or any other part of
>> > 'multiprocessing' isn't imported by your simple test case, as far as I
>> > can tell -- and setuptools definitely doesn't import it either. But
>> > your errors are in the multiprocessing.util module. So, something else
>> > must be importing it.
>
> Where does the simple test case you sent me load multiprocessing,
> then? If I were debugging this, I'd put a pdb.set_trace() at the top
> of multiprocessing/__init__.py and then print out the stack to see
> where the heck it's being imported from.
Good idea. Here we go:
$ ./setup.py test
running test
running egg_info
writing UNKNOWN.egg-info/PKG-INFO
writing top-level names to UNKNOWN.egg-info/top_level.txt
writing dependency_links to UNKNOWN.egg-info/dependency_links.txt
reading manifest file 'UNKNOWN.egg-info/SOURCES.txt'
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
running build_ext
test_getattr_root (tests.t3_fs_api.fs_api_tests) ... > /usr/lib/python2.6/multiprocessing/__init__.py(46)<module>()
-> __version__ = '0.70a1'
(Pdb) where
/home/nikratio/tmp/setup.py(28)<module>()
-> test_suite='tests',
/usr/lib/python2.6/distutils/core.py(152)setup()
-> dist.run_commands()
/usr/lib/python2.6/distutils/dist.py(975)run_commands()
-> self.run_command(cmd)
/usr/lib/python2.6/distutils/dist.py(995)run_command()
-> cmd_obj.run()
/home/nikratio/.local/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/test.py(121)run()
-> self.with_project_on_sys_path(self.run_tests)
/home/nikratio/.local/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/test.py(101)with_project_on_sys_path()
-> func()
/home/nikratio/.local/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/setuptools/command/test.py(130)run_tests()
-> testLoader = loader_class()
/usr/lib/python2.6/unittest.py(817)__init__()
-> self.runTests()
/usr/lib/python2.6/unittest.py(861)runTests()
-> result = testRunner.run(self.test)
/usr/lib/python2.6/unittest.py(753)run()
-> test(result)
/usr/lib/python2.6/unittest.py(464)
-> test(result)
/usr/lib/python2.6/unittest.py(464)__call__()
-> return self.run(*args, **kwds)
/usr/lib/python2.6/unittest.py(460)run()
-> test(result)
/usr/lib/python2.6/unittest.py(464)__call__()
-> return self.run(*args, **kwds)
/usr/lib/python2.6/unittest.py(460)run()
-> test(result)
/usr/lib/python2.6/unittest.py(464)__call__()
-> return self.run(*args, **kwds)
/usr/lib/python2.6/unittest.py(460)run()
-> test(result)
/usr/lib/python2.6/unittest.py(464)__call__()
-> return self.run(*args, **kwds)
/usr/lib/python2.6/unittest.py(460)run()
-> test(result)
/usr/lib/python2.6/unittest.py(300)__call__()
-> return self.run(*args, **kwds)
/usr/lib/python2.6/unittest.py(279)run()
-> testMethod()
/home/nikratio/tmp/tests/t3_fs_api.py(12)test_getattr_root()
-> log.info('Woops!')
/usr/lib/python2.6/logging/__init__.py(1030)info()
-> self._log(INFO, msg, args, **kwargs)
/usr/lib/python2.6/logging/__init__.py(1142)_log()
-> record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra)
/usr/lib/python2.6/logging/__init__.py(1117)makeRecord()
-> rv = LogRecord(name, level, fn, lno, msg, args, exc_info, func)
/usr/lib/python2.6/logging/__init__.py(272)__init__()
-> from multiprocessing import current_process
> /usr/lib/python2.6/multiprocessing/__init__.py(46)<module>()
-> __version__ = '0.70a1'
I think that it really is the logging module.
>> And only with setuptools it produces exceptions.
>
> You're testing the wrong thing. What you want to be testing is the
> difference between the environments where it works with setuptools,
> and where it doesn't work with setuptools. All that you've shown is
> that setuptools is *related* to the problem; there's still the
> possibility of a plugin interfering.
Well, the way it looks to me is that in this constellation the use of
setuptools seems to produce bogus error messages in the multiprocessing
module. Why is it so important what loads the multiprocessing module?
Can't we just assume that I send the test case with an additional
'import multiprocessing' line?
Sorry if I'm missing your point. I just can't quite follow you.
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
More information about the PEAK
mailing list