Andrew Straw wrote: > Michael Droettboom wrote: > >> A couple more comments about the test framework -- which has already >> paid for itself ten times over. In Numpy (and a number of local >> Python projects), I can 'cd' to the tests directory and do something >> like: >> >> nosetests test_simplification.py:test_hatch_simplify >> >> and run on particular test, or a single file of tests. It's a huge >> time saver when trying to fix a bug. However, with matplotlib I get: >> >> > nosetests test_simplification.py >> E >> ====================================================================== >> ERROR: Failure: ImportError (cannot import name cbook) >> <snip> >> I suspect this is something peculiar to how matplotlib gets imported. >> > > Yes, it would be very nice, I absolutely agree. I'm not sure what's > going on, either, but I agree that it would be nice to fix. See below > for an idea. > > >> Also, I have a quad-core machine, so I put this in my .noserc, which >> will run tests in parallel: >> >> [nosetests] >> processes=4 >> >> Unfortunately, due to however matplotlib is delegating to nose, this >> doesn't seem to get picked up. >> >> I don't know if I'll get a chance to look at these things right away, >> but thought I'd share in case the solutions are obvious to anyone >> else (which I know isn't good form, but hey... ;) >> > My guess is that this may actually be related to the first issue. On > this second issue, though, I have a specific idea -- in order for MPL > to pickup the nose plugin, I had to do the song and dance in test() of > matplotlib/__init__.py in which I create a nose.config.Config > instance. I suspect this is why your processes argument isn't getting > through -- we're completely bypassing any local nose config and > creating ours programattically. I'm definitely not in favor the big > song and dance, so if you can rip it out and still get the plugin to > load, that would be super. > > Once that is figured out, presumably the direct call to "nosetests > test_simplification.py:test_hatch_simplify" will also load the nose > plugins and thus not exhibit weird behavior when a known failure is > encountered. > > I almost certainly won't get a chance to look at these right away, so > if anyone wants to go spelunking in the nose/mpl interaction, feel free. I have a partial solution to these problems.
You can now do (from any directory) nosetests matplotlib.tests and this automatically picks up nose parameters, so you can do multiprocessing, pdb, coverage and other nose niceties. Strangely, I still can't make running "nosetests" from the lib/matplotlib/tests directory work. The imports seem to get all screwed up in that case, presumably because nose is messing with sys.path. Unfortunately, nosetests -P (which is supposed to not touch sys.path) doesn't seem to help. I made sure that "import matplotlib; matplotlib.test()" still works, so the buildbots should be unaffected. As a side note, I disabled the xmllint testing since curl (which xmllint uses to fetch the SVG DTD) has some problems with caching in a multiprocess situation. It gives random "Operation in progress" errors. Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
