8000 WIP: Test in a minimal Python configuration by mdboom · Pull Request #11281 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

WIP: Test in a minimal Python configuration #11281

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

Closed
wants to merge 1 commit into from

Conversation

mdboom
Copy link
Member
@mdboom mdboom commented May 21, 2018

This removes most of the optional Python modules and makes sure basic
matplotlib functionality still works. See discussion in #11263 for motivation.

Marking as "WIP" just because this stuff usually takes a while to get right on Travis.

PR Summary

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

This removes most of the optional Python modules and makes sure basic
matplotlib functionality still works.
@mdboom mdboom requested a review from anntzer May 21, 2018 17:28
# separate, more limited process.

PYTEST_REQUIREMENTS = [
'_posixsubprocess', 'select', 'binascii', 'pyexpat', '_socket'
Copy link
Contributor

Choose a reason for hiding this comment

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

What's your plan with these? Especially subprocess, which I guess is likely unavailable in js systems, but has become a hard dependency now that we killed matplotlib.compat.subprocess? (In reality I think systems that have no support for subprocess should still provide a shim module that throws in the Popen constructor, which is easy to provide and avoids all downstream projects from having to provide such a shim.)

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't have a certain plan, other than to run the tests in a separate Python from py.test itself, which should be possible with pytest-xdist. It's made even more complicated by the fact that matplotlib's own testing framework also needs subprocess (to run inkscape and ghostscript etc.) Lord knows what the performance will be like. I sort of see this as a first pass of "better than nothing for now."

Copy link
Contributor

Choose a reason for hiding this comment

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

Again, how hard would it be for pyodide to just provide shims of subprocess and multiprocessing similar to https://github.com/matplotlib/matplotlib/blob/v2.2.2/lib/matplotlib/compat/subprocess.py (which we have recently removed)?
That'll make life easier for all downstream projects...

Copy link
Member Author

Choose a reason for hiding this comment

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

What we be the purpose of this if it didn't actually work? Just to get things to import?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes. It seems to be a bit excessive to ask each and every project to wrap their "import subprocess" (most of which are at the toplevel) in a try... except; at least if you provide shims then the discussion becomes "what features of the project don't work when subprocess isn't present" rather than "the thing doesn't even import".

if modulename not in KEEP_MODULES:
yield modulename

# Some other commonly-missing modules that aren't in Setup.dist
Copy link
Contributor

Choose a reason for hiding this comment

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

If you're going to hardcode a list there you may as well do without Setup.dist and just hardcode the entire list...

Copy link
Member Author

Choose a reason for hiding this comment

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

Perhaps. Some of the stuff is optional due to Setup.dist, and some things are turned on/off by environment tests in CPython's configure script. The latter is harder to pick out automatically, but maybe not impossible.

@tacaswell tacaswell added this to the v3.0 milestone May 22, 2018
@tacaswell tacaswell modified the milestones: v3.0, v3.1 Jul 9, 2018
@anntzer
Copy link
Contributor
anntzer commented Oct 8, 2018

See also https://bugs.python.org/issue34895 for cpython work on listing "optional" modules.

@jklymak jklymak modified the milestones: v3.1.0, unassigned Feb 9, 2019
@jklymak jklymak added the stale label Jul 23, 2020
@jklymak jklymak marked this pull request as draft July 23, 2020 16:41
@jklymak
Copy link
Member
jklymak commented Jun 14, 2021

Closing as abandoned, but of course re-open if still pursuing this ;-)

6D8D
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
0