[PEAK] Re: setuptools test command generates exception after interpreter shutdown

P.J. Eby pje at telecommunity.com
Mon May 3 21:03:50 EDT 2010


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)


> > 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.
>
>Yes, it seems to be the logging module. If I remove it, then 
>multiprocessing is no longer loaded.

I don't think that's it, either -- logging never imports 
multiprocessing; it only *uses* it if it's already imported.  So, 
there still appears to be something else in your environment that's relevant.


>  But the multiprocessing module is loaded both with- and without setuptools.

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.


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



More information about the PEAK mailing list