You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
BUG: Qt5Agg / PyQt5 not compatible with macOS Big Sur #18954
I have Qt5Agg set as my default backend. I recently upgraded my macOS system to Big Sur, and now import matplotlib.pyplot as plt; plt.figure() ends up hanging the interpreter. It seems like this is really a PyQt5 problem, but I thought I'd post some sort of information here as a bit of a warning for people, and as a place for people to mention workarounds if they have them. Or maybe I'm the only one with this problem, in which case sorry for the noise! FWIW I tried PyQt5 5.12 and 5.15.1, same problem on both. I also tried pyside2, it at least does not hang but no window is shown.
In the meantime I'll probably set my backend to MacOSX.
EDIT: My matplotlibrc specifies both backend: Qt5Agg and interactive: True
After some investigation, it looks like importing matplotlib.backends._tkagg for some reason fixes things:
from matplotlib.backends import _tkagg
import matplotlib.pyplot as plt
fig = plt.figure()
assert 'QTAgg' in fig.canvas.__class__.__name__
It looks like that's a compiled module, I'll see if it sets some system-level stuff to make itself work. Maybe that's what we need to do for PyQt5 on Big Sur...
Based on seeing in one of the linked issues that the SDK will give conflicting answers based on who it thinks is asking. My guess is that loading tk forces the SDK in to "old" mode which gives back qt an answer that it likes. If that is the case so level of PRE_LOAD would also "fix" the problem.
I was also told on the PyQt5 mailing list that 5.15.2 will have this QT_MAC_WANTS_LAYER on by default. But that won't help people with previous versions...
I don't think we have to do anything about this right now, but leaving open as a signpost.
Agreed it's not really matplotlib's problem. However, one option to try to save people some pain would be to add a platform.mac_ver() + os.getenv('QT_MAC_WANTS_LAYER') check in the PyQt5 backend, and warn people. This seems like an easy backport to the current maintained branches. The only real downside I see (other than it adding a handful of lines and the associated, hopefully low maintenance burden) is that this runs the risk of warning people who don't need to be warned if it turns out not to be a universal problem. To me the benefit it would bring to people who have their interpreter inexplicably hang would be worth this, but that's easy for me to say since I wouldn't be the one maintaining the new mpl lines :)
and just to be sure, I've checked that echo $QT_MAC_WANTS_LAYER doesn't print anything. Any ideas if there's something else I need to be doing to reproduce the bug?
I never went as far back as 5.9 in the Qt versions. Doing some installs locally it looks like there is no problem on 5.11.3 (as far back as I could go with my Python 3.8 install using pip) but on 5.12.3 or above I can reproduce the issue with your snippet.
Activity
larsoner commentedon Nov 15, 2020
I assume that this is the upstream issue:
https://bugreports.qt.io/browse/QTBUG-85546
I also posted to the PyQt5 mailing list about this. I'll update this if I get more information.
larsoner commentedon Nov 15, 2020
I noticed that there is a StackOverflow post about this:
https://stackoverflow.com/questions/64833558/apps-not-popping-up-on-macos-big-sur-11-0-1/64847505#64847505
After some investigation, it looks like importing
matplotlib.backends._tkaggfor some reason fixes things:It looks like that's a compiled module, I'll see if it sets some system-level stuff to make itself work. Maybe that's what we need to do for PyQt5 on Big Sur...
larsoner commentedon Nov 15, 2020
Actually importing
tkinteror_tkinter(the C.sothatimport tkinterimports) is enough:So I guess there is some magic in here?
https://github.com/python/cpython/blob/a26215db11cfcf7b5f55cab9e91396761a0e0bcf/Modules/_tkinter.c#L3465-L3646
EDIT: I'm guessing it's the
inputhookor TCL code somehow, but this is too low-level for me personally to know.[-]BUG: Qt5Agg / PyQt5 not compatible with BigSur[/-][+]BUG: Qt5Agg / PyQt5 not compatible with macOS Big Sur[/+]tacaswell commentedon Nov 15, 2020
Based on seeing in one of the linked issues that the SDK will give conflicting answers based on who it thinks is asking. My guess is that loading tk forces the SDK in to "old" mode which gives back qt an answer that it likes. If that is the case so level of
PRE_LOADwould also "fix" the problem.larsoner commentedon Nov 17, 2020
A suitable workaround seems to be
QT_MAC_WANTS_LAYER=1, found on the PyQt5 mailing list via https://stackoverflow.com/questions/64818879/is-there-any-solution-regarding-to-pyqt-library-doesnt-work-in-mac-os-big-sur/64856281 and https://forums.macrumors.com/threads/pyqt5-and-big-sur.2260773/?post=29243620#post-29243620tacaswell commentedon Nov 17, 2020
Given that this seems to be generic to pyqt, I don't think we have to do anything about this right now, but leaving open as a signpost.
larsoner commentedon Nov 18, 2020
I was also told on the PyQt5 mailing list that 5.15.2 will have this
QT_MAC_WANTS_LAYERon by default. But that won't help people with previous versions...Agreed it's not really matplotlib's problem. However, one option to try to save people some pain would be to add a
platform.mac_ver()+os.getenv('QT_MAC_WANTS_LAYER')check in the PyQt5 backend, andwarnpeople. This seems like an easy backport to the current maintained branches. The only real downside I see (other than it adding a handful of lines and the associated, hopefully low maintenance burden) is that this runs the risk of warning people who don't need to be warned if it turns out not to be a universal problem. To me the benefit it would bring to people who have their interpreter inexplicably hang would be worth this, but that's easy for me to say since I wouldn't be the one maintaining the new mpl lines :)dstansby commentedon Jan 22, 2021
I'm struggling to reproduce this issue. I have these versions installed:
and the following script is working fine for me, on macos 11.1:
and just to be sure, I've checked that
echo $QT_MAC_WANTS_LAYERdoesn't print anything. Any ideas if there's something else I need to be doing to reproduce the bug?larsoner commentedon Jan 22, 2021
I never went as far back as 5.9 in the Qt versions. Doing some installs locally it looks like there is no problem on 5.11.3 (as far back as I could go with my Python 3.8 install using
pip) but on 5.12.3 or above I can reproduce the issue with your snippet.tacaswell commentedon Jan 22, 2021
The conda packaged versions of Qt are getting painfully old these days...
dstansby commentedon Jan 22, 2021
😆 well I seem to get a different error with 5.12.2 (will open a new issue), but I can confirm this with 5.15.1
dstansby commentedon Jan 22, 2021
Huh, now I've re-installed 5.12.2 it seems to be working fine.
dstansby commentedon Apr 5, 2021
I think this is closed by #19334? If anyone disagrees please leave a comment or re-open.