Sounds like a very good idea to me

Yes. Spyder's needs of Qt are much more complex than ours, so I suspect it should do everything we need it to do.

spyder-ide/qtpy#84 <- they now support pyside2 so are back to wrapping parity.

See #9993 (comment) for arguments against it.

I think spyder-ide/qtpy#138 needs to be fixed first by them.

Edit: my PR to fix the issue went in.

Upon further thought, I am against switching to qtpy. The main reason for this is that we already don't declare a dependency on any qt binding, and I guess we wouldn't declare a dependency on qtpy either. Likewise, qtpy does not (by design) declare a dependency on any qt binding. The end result is that you'd have to add yet another manual dependency management step for whoever wants to install matplotlib+qt from pypi.

Not sure if this really works and is an accepted way of doing things, but could we create a placeholder package matplotlib-qt, that will basically only resolve the required dependencies when installing it with pip?

That doesn't really help, as the main sticking point is that multiple underlying qt bindings are supported (unless you want to create matplotlib-pyqt4, matplotlib-pyqt5, matplotlib-pyside, matplotlib-pyside2, but meh).

All of them are an overkill, but maybe we declare one of them (pyside2 in the long run?) the preferred choice. Then there would be a simple way for the "standard" installation. If people want to use other bindings, they can but have to resolve the dependencies themselves.

We have to keep supporting all the qt bindings and probably should not pick an (official) favorite. We definitely can not pick up any dependencies on GUI bindings on pypi by default. We probably should be using the 'extras' part of setup.py a bit more effectively though to support pip install matplotlib[pyside2] etc.

The advantage of moving to qtpy is that we can deprecate all of our binding selection logic and off-load it to qtpy. We are then automatically in sync with any other project that uses qtpy (there is nothing more frustrating that trying to use more than one package that is opinionated about how to import qt bindings....).

The advantage of moving to qtpy is that we can deprecate all of our binding selection logic and off-load it to qtpy. We are then automatically in sync with any other project that uses qtpy (there is nothing more frustrating that trying to use more than one package that is opinionated about how to import qt bindings....).

I think this would only be true if you decide to kill the qt4agg and qt5agg backends and replace them by a single qtagg backend, because otherwise we would still need to maintain code to override the backend selection logic to force either qt4 (pyqt4/pyside) or qt5 (pyqt5/pyside2). (TBH I actually wouldn't mind doing such a deprecation, but I won't be the one making the call...)

Is this still needed now that Qt4 is deprecated since Matplotlib 3.3?

Depends on how Qt6 goes, I guess?

Do we need to/would this cover also PySide2? I not I propose to close this as Qt6 is not yet there and we don't need to hold the PR open just in case it may become relevant.

Closing. The last discussion was 2 years ago. If new reasons to switch to qtpy arise, a new issue can be opened.