I think we need this function to be able to run the tests against a "proper" install rather than a source install. IIRC@QuLogic uses this in the fedora packaging.

Maybe it's my ignorance on the topic, I would have thought that proper install or editable install doesn't make a difference for testing. But happy to learn something new.

If this is only needed for packagers, we could still make it private and/or move it tomatplotlib.testing. A top-levelmatplotlib.test() seems too prominent.

I don't use it directly, but throughtests.py. But as that's basically a wrapper around pytest, I think it should be possible to switch to it.

You should also confirm what happens on Debian, cc@sandrotosi

Maybe it's my ignorance on the topic, I would have thought that proper install or editable install doesn't make a difference for testing. But happy to learn something new.

There are some difficulties in how pytest auto-discovery works if you naively run thepytest CLI tool in the source tree (see discussion in#20312) with Matplotlib "properly" installed.

Ah, might have to do with the test files being part of the package? I have to admit, that I have never really understood how pytest sets up the environment.

I have to admit, that I have never really understood how pytest sets up the environment.

pytest is very magical (which is both the best and worst thing about it!).

No, not really, you just have to ensure thatPYTHONPATH points to a complete copy, and pass--pyargs, which is whattest does.

It also does extensive dependancy injection and re-writes the byte code!

I don't use it directly, but throughtests.py. But as that's basically a wrapper around pytest, I think it should be possible to switch to it.

You should also confirm what happens on Debian, cc@sandrotosi

yep, Debian does the same (thanks for checking!)

I've switched Fedora to usepytest directly, so this is okay to do from its point of view. The only annoyance was that it had to use--pyargs mpl_toolkits.tests instead of plainmpl_toolkits because it's a namespace.

@QuLogic thanks for checking! Could you amend the deprecation notice with your findings to prevent any stumbling blocks? I'm not sure what needs to be explained so that currentmatplotib.test() users can switch seamlessly.

This is not urgent. We can push this to 3.6 if there is too much 3.5 stuff still to do.