Webagg backend: get rid of tornado

[martinRenou]

PR Summary

This allows using the webagg backend in JupyterLite, by replacing tornado with asyncio. See matplotlib/ipympl#334 and https://github.com/jtpio/jupyterlite/pull/219

cc. @davidbrochart

PR Checklist

• Has pytest style unit tests (and pytest passes).
• Is Flake 8 compliant (run flake8 on changed files to check).
• New features are documented, with examples if plot related.
• Documentation is sphinx and numpydoc compliant (the docs should build without error).
• Conforms to Matplotlib style conventions (install flake8-docstrings and run flake8 --docstring-convention=all).
• [N/A] New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
• [N/A] API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).

[tacaswell]

This seems like a major API change? We either need replacements/backcompat shims or a very clear API change note for the classes that no longer exist.

Does this put a floor on our tornado support to versions that know howto play nice with asyncio?

[martinRenou]

I guess we could keep the timertornado class around? And do a lazy import of tornado if one uses it.

This way the PR would just be about adding a new timer class that doesn't need tornado, and that ipympl could use.

[anntzer]

I don't know enough about the ecosystem (whether the jupyter side or the async side :-)) to have an answer here, but do you think anyone is actually relying on the tornado timer? Could it be reasonably deprecated? Or perhaps more mildly, moved to backend_webagg, and make backend_webagg_core a "you need to provide your own timer" abstract backend?

[martinRenou]

Given the comments and concerns about backward compatibility, I've put back the TimerTornado.

Having the TimerTornado around is harmless in a "pyodide" context like JupyterLite as long as tornado is imported lazily, so we can definitely keep it.

[stonebig]

is there still hope on this for 3.5.0 ?

[tacaswell]

@stonebig It looks like there are still a few back-compatibility changes that need to be addressed.

We have not "feature frozen" for 3.5 yet, can you give me a sense of how important / impactful getting this in would be?

[stonebig]

For a windows user, Tornado is non-performant.
Martin writes this is also a stone to remove to improve wasm / web flight envelop of python Jupyter stack.

So my interest to push this, as I believe it will have positive effects for python on web and python on windows. Nothing more.

[tacaswell]

This PR is affected by a re-writing of our history to remove a large number of accidentally committed files see discourse for details.

To recover this PR it will need be rebased onto the new default branch (main). There are several ways to accomplish this, but we recommend (assuming that you call the matplotlib/matplotlib remote "upstream"

git remote update
git checkout main
git merge --ff-only upstream/main
git checkout YOUR_BRANCH
git rebase --onto=main upstream/old_master
# git rebase -i main # if you prefer
git push --force-with-lease   # assuming you are tracking your branch

If you do not feel comfortable doing this or need any help please reach out to any of the Matplotlib developers. We can either help you with the process or do it for you.

Thank you for your contributions to Matplotlib and sorry for the inconvenience.

[ArchangeGabriel]

I’m packaging matplotlib for ArchLinux and I have some questions regarding this changes:

• the documentation (nor tests env, etc.) wasn’t updated and still says tornado is required for the webagg backend, is that correct?
• if it’s not, in what cases is tornado still required?

[martinRenou]

It is still needed, because the webagg backend provides a TornadoTimer class that might be used by dependencies (and by other places in Matplotlib?)

But in the long term the dependency might be removed?

Please someone correct me if I am wrong.

[tacaswell]

The important change here is that backend_webagg_core no longer requires tornado. This is the module that ipympl imports and hence hiding the tornado import at that level removes an implicit tornado dependency from ipympl.

However backend_webagg.py still very much depends on tornado, the core application class is

matplotlib/lib/matplotlib/backends/backend_webagg.py

Lines 54 to 57 in 49609c3

	class WebAggApplication(tornado.web.Application):
	initialized = False
	started = False

!

We may want to rename this as backend_webagg_tornado and add a backend_webagg_fastapi, backend_webagg_aiohttp, (or maybe make those one ones sibling projects in mpl and also eject the tornado one?).