Skip to content

Deprecate matplotlib.test() #20586

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 24, 2021
Merged

Conversation

timhoffm
Copy link
Member

@timhoffm timhoffm commented Jul 6, 2021

This is not a function that can be easily executed by the end user with a standard setup. Testing requires substantial setup such as installing additional dependencies and reference data. A function matplotlib.test() gives the false impression that a user can simply call it to verify if Matplotlib is working correctly. Running pytest explicitly has become a de-facto standard and allows users to customize the run by various command line arguments. There is no point in having a second own and more limited entry point to tests.

@timhoffm timhoffm force-pushed the deprecate-test branch 2 times, most recently from 033f462 to 45bcd44 Compare July 6, 2021 21:08
@tacaswell
Copy link
Member

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.

@tacaswell tacaswell requested a review from QuLogic July 6, 2021 22:26
@tacaswell tacaswell added this to the v3.5.0 milestone Jul 6, 2021
Copy link
Member

@tacaswell tacaswell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need this to support testing installed versions (primarily to support the packagers). @QuLogic can dismiss this with prejudice if I am wrong.

@timhoffm
Copy link
Member Author

timhoffm commented Jul 6, 2021

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 to matplotlib.testing. A top-level matplotlib.test() seems too prominent.

@QuLogic
Copy link
Member

QuLogic commented Jul 6, 2021

I don't use it directly, but through tests.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

@tacaswell
Copy link
Member

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 the pytest CLI tool in the source tree (see discussion in #20312) with Matplotlib "properly" installed.

@timhoffm
Copy link
Member Author

timhoffm commented Jul 6, 2021

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.

@timhoffm timhoffm marked this pull request as draft July 6, 2021 23:08
@tacaswell
Copy link
Member

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

@QuLogic
Copy link
Member

QuLogic commented Jul 6, 2021

No, not really, you just have to ensure that PYTHONPATH points to a complete copy, and pass --pyargs, which is what test does.

@tacaswell
Copy link
Member

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

@sandrotosi
Copy link
Contributor

I don't use it directly, but through tests.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!)

@QuLogic
Copy link
Member

QuLogic commented Aug 21, 2021

I've switched Fedora to use pytest 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 plain mpl_toolkits because it's a namespace.

@tacaswell tacaswell self-requested a review August 21, 2021 16:31
@timhoffm
Copy link
Member Author

@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 current matplotib.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.

This is not a function that can be easily executed by the end user with
a standard setup.  Testing requires substantial setup such as installing
additional dependencies and reference data.  A function
`matplotlib.test()` gives the false impression that a user can simply
call it to verify if Matplotlib is working correctly.  Running pytest
explicitly has become a de-facto standard and allows users to customize
the run by various command line arguments.  There is no point in having
a second own and more limited entry point to tests.
@QuLogic QuLogic marked this pull request as ready for review August 24, 2021 00:26
Copy link
Member

@QuLogic QuLogic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay with this, though I wrote some of the API change note.

@tacaswell tacaswell merged commit b4251e6 into matplotlib:master Aug 24, 2021
@timhoffm timhoffm deleted the deprecate-test branch August 24, 2021 06:11
@anntzer anntzer mentioned this pull request May 27, 2022
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants