Hi Mike,

On Tue, Jun 18, 2013 at 3:37 PM, Michael Droettboom <md...@stsci.edu> wrote:
> This was an attempt to fix a bug that mpl's KnownFailure plugin wouldn't
> load when running tests directly using the nosetests commandline
> script.  I see IPython has a testing wrapper script (iptest) -- is that
> in part to solve that problem?

Only in part. We wrote iptest because we need to start nose multiple
times in different subprocesses for each chunk of IPython, as trying
to load all of IPython into a single python process ends up producing
tears (conflicts between things that don't like to live together in
sys.modules like multiple gui toolkits, etc).

> In any case, the revert should be simple -- can you try commenting out
> the "entry_points" kwarg at the bottom of the setup.py script?  (You'll
> probably need to blitz the matplotlib installation directory and `build`
> for good measure).  I can't actually reproduce the bug myself, but I
> suspect that's because this is somewhat dependent on the order in which
> things are installed into the virtualenv or the phases of the moon...

Yup, problem gone. With this change:

((v1.3.0rc3))longs[matplotlib]> git diff
diff --git a/setup.py b/setup.py
index 5f1b561..b4d1763 100644
--- a/setup.py
+++ b/setup.py
@@ -230,9 +230,9 @@ if __name__ == '__main__':
           zip_safe=False,

           # Install our nose plugin so it will always be found
-          entry_points={
-              'nose.plugins.0.10': [
-                  'KnownFailure = matplotlib.testing.noseclasses:KnownFailure'
-                ]
-            },
+         # entry_points={
+         #     'nose.plugins.0.10': [
+         #         'KnownFailure = matplotlib.testing.noseclasses:KnownFailure'
+         #       ]
+         #   },
          )

I get as expected:

((v1.3.0rc3))longs[matplotlib]> iptest -vx IPython.core.tests.test_run

[...]

----------------------------------------------------------------------
Ran 23 tests in 2.277s

OK (KNOWNFAIL=1)

> If that works for you, we can just take that out and require testers to
> use our testing script (and unfortunately will have to make another
> release candidate).

Well, I wouldn't want to force mpl to have to ship a custom testing
script, that's kind of an ugly kludge that we live with but that is
really sub-optimal.  I wish we could just fix this plugin issue. The
problem, I suspect, is the presence of multiple KnownFailure classes
in a way that trips an isisnstance() check somewhere.

Cheers,

f

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to