Repository navigation
Dropping support for PyQt4; preparing support for PyQt6. #16836
Description
PyQt4 is getting increasingly difficult to test (I wrote this issue following #16834). AFAICT,
- there are no official wheel releases (https://pypi.org/project/PyQt4/),
- anaconda only has packages up to Py3.5 (https://anaconda.org/anaconda/pyqt/files?version=4.11.4)
- conda-forge only has packages up to Py3.6 (https://anaconda.org/conda-forge/pyqt/files?version=4.11.4)
- Christopher Gohlke has Windows wheels for Py3.7 as well (https://www.lfd.uci.edu/~gohlke/pythonlibs/#pyqt4) (*)
- I haven't surveyed linux distros, but at least Arch Linux has dropped Qt4 from its official repos (https://aur.archlinux.org/packages/qt4/#pinned-693093).
Matplotlib 3.3 will likely not be released before mid-2020(?) which means that it will require Python 3.7+ -- Python 3.6.0 was released in December 2016 (https://docs.python.org/3.6/whatsnew/3.6.html). This means that in practice, the only setup which Matplotlib 3.3 and and PyQt4 can even coexist at all is Windows + Py3.7 + Christopher Gohlke's wheel.
I therefore propose to deprecate the qt4{agg,cairo} backends in Matplotlib 3.3. (From now on I'll just write qtXagg but everything applies just as well to qtXcairo.)
Qt6 is planned for the end of 2020 (https://www.qt.io/blog/2019/08/07/technical-vision-qt-6) and PyQt6 should follow soon after (http://python.6.x6.nabble.com/Wondering-about-PyQt6-td5249539.html). However, instead of introducing a new qt6agg backend, I propose to name the new backend qtagg instead -- with the idea to soft-deprecate qt5agg (this can stay for very long, until qt5 itself dies off just like qt4 did), with the idea that selecting qtagg will just select a qt version based on what's available and on QT_API. This will avoid the currently slightly confused fallback system where we sometimes fallback from qt4 to qt5 or vice-versa depending on what's available, so the version numbers are not really compulsory anyways... This is assuming that PyQt5 and PyQt6 are indeed close enough that it makes sense to implement support for both in a single module -- obviously, we'll only know that once PyQt6 is released.
Activity
QuLogic commentedon Mar 20, 2020
PyQt4 seems to be in many distros: https://repology.org/project/python:pyqt4/versions but of course, that doesn't really say what their future plans are.
anntzer commentedon Mar 20, 2020
Looks like Debian is in the process of removing Qt4 as well (https://wiki.debian.org/Qt4Removal) and I guess this means Ubuntu will follow suit soon.
I don't know what Fedora's plans are, but you may be more aware of them than me? ;)
Looking at the repology list, the only remaining "major" (as listed in https://en.wikipedia.org/wiki/Linux_distribution#Widely_used_distributions, which I guess is fairly generous...) distros with PyQt4 packaged (other than those above) are Mageia7 and Slackware (CentOS7, Scientific Linux 7, PCLinuxOS, and OpenSUSE 15 also have it, but they're limited to Py3.6 so already not compatible with the next Matplotlib release).
hugovk commentedon Mar 20, 2020
Qt 4 reached end-of-life on 2015-12-19. Its Python bindings are also EOL: PyQt4 since 2018-08-31 and PySide since 2015-10-14.
We deprecated PyQt4 and PySide in Pillow 6.0.0 (April 2019) and removed them in 7.0.0 (January 2020) and have had no issues reported about PyQt4 since before the deprecation.
https://pillow.readthedocs.io/en/stable/deprecations.html#pyqt4-and-pyside
QuLogic commentedon Mar 20, 2020
I think there are not any plans to drop Qt4 in Fedora, mainly because of one maintainer keen to keep older KDE around. Since it's deprecated upstream, I would guess that PyQt4 will stick around until it fails to build with Python 3.
tacaswell commentedon Mar 22, 2020
We require pillow >= 6.2 on master branch so does that mean we have already effectively already dropped support for pyqt4?
timhoffm commentedon Mar 22, 2020
You could still use pillow<7 with pyqt4 (but get a deprecation warning).
tacaswell commentedon Mar 22, 2020
🐑 sorry, miss understood.
anntzer commentedon Mar 22, 2020
We also don't rely on Pillow's Qt integration (which is not enough for us anyways) so in theory we could still work with Pillow 7 and PyQt4.
I think it's more a question of when, if ever, do we want to pull the plug on PyQt4 given that it is simply getting more and more difficult to test it.
OTOH I don't mind waiting for PyQt6 to come out and at least see what the landscape is going to be at that point (e.g. will we have a single qtagg, as I'd like, or both qt5agg and qt6agg)? -- it's just a couple more months anyways...
hugovk commentedon Mar 23, 2020
Apologies if my comment caused confusion, it was intended as a data point for another library dropping support for PyQt4 and receiving no negative feedback about it.
I agree with deprecating PyQt4 in Matplotlib 3.3, it's been EOL for years. The idea of NEP 29, is to reduce community burden by only supporting a subset of non-EOL CPython and NumPy.
In a similar spirit, dropping EOL PyQt4 would reduce the maintenance burden of Matplotlib and potentially other community projects.
QuLogic commentedon May 23, 2020
Support for Qt4 was deprecated in #16836, so the only thing left here is to decide how to support Qt6, or can we close?
anntzer commentedon May 23, 2020
we can close this for now and revisit when pyqt6 is out.
jiten597 commentedon Feb 9, 2021
Hello Guyz.
Please help me to make below code (made in PyQt4) in PyQt6.
QtCore.QObject.connect(self.radioButton_UserDefinedCoordinate, QtCore.SIGNAL(_fromUtf8("toggled(bool)")), self.label_5.setEnabled)
timhoffm commentedon Feb 9, 2021
@jiten597 This the Matplotlib issue tracker, not a Qt help forum. We can’t help you.