PyPlot works but calling matplotlib directly from PyCall aborts

[musm]

julia> using PyCall

julia> plt = pyimport("matplotlib.pyplot")
PyObject <module 'matplotlib.pyplot' from 'C:\\tools\\Miniconda3\\lib\\site-packages\\matplotlib\\pyplot.py'>

julia> x = range(0; stop=2*pi, length=1000); y = sin.(3 * x + 4 * cos.(2 * x));

julia> plt.plot(x, y)
This application failed to start because it could not find or load the Qt platform plugin "windows"
in "".

Reinstalling the application may fix this problem.

This causes Julia to terminate abruptly.

Yet using PyPlot works ?

[stevengj]

PyPlot works because it uses a different backend, presumably.

Some of the Matplotlib backends only seem to work with the python executable, though I'm not sure why in this particular case — PyPlot usually works with Qt.

[musm]

@stevengj I did some investigating to see if loading the matplotlib package with PyCall vs loading it with PyPlot was somehow loading the wrong dll leading to the crash, via process explorer.

However that confirmed BOTH methods loaded the exact same dll's (backend for both is QT5)

[tkf]

Maybe call pygui_start(:qt_pyqt5)? That's another difference to PyPlot. Although I guess it only matters if you have non-default Qt configuration.

[stevengj]

By default, Matplotlib starts in non-interactive mode, so you shouldn't need a pygui event loop in Julia. The plot window doesn't appear until you run plt.show(), in which case Python implements the event loop.

[stevengj]

There are multiple Python Qt libraries. Maybe PyPlot is importing a different one and Matplotlib is respecting that? See https://github.com/JuliaPy/PyPlot.jl/blob/master/src/init.jl

[musm]

It's quite strange because calling matplotlib from python works, PyPlot works, just from PyCall it fails.

[tkf]

pygui_start(:qt_pyqt5) calls fixqtpath before starting the event loop. I thought it could be doing something.

[stevengj]

Oh right, I forgot about fixqtpath(). You could definitely try calling PyCall.fixqtpath() manually.

(Retitling this issue because I wouldn't call this silent or a crash — matplotlib is aborting with an error message.)

[musm]

Yes calling PyCall.fixqtpath() manually after import matplotlib fixes the issue. @tkf it seems PyCall.fixqtpath() is good enough to avoid the crash.

We'll the error ends up killing julia, which is pretty annoying. Is that avoidable?

[tkf]

Yeah, it'd be nice if we can avoid it. Though I don't know what's the best way to do it. Is it too crazy to always call fixqtpath in PyCall.__init__?

[musm]

Doesn't seem too crazy, until a proper fix is implemented. Are there any other instances that can crash julia like this or is it only the QT path loading issue.

[stevengj]

I guess since fixqtpath just sets an environment variable, it is not so bad to run unconditionally on startup for Windows. (Only mildly insane, but we are used to that. 🙄 )

Any library that calls os.abort() or similar will terminate Julia (or any other program). This is not a "crash" in the usual sense, and it is impossible to prevent in general.

A "proper" fix here would be to fix Qt (or its Python wrapper) to either be more robust about finding library paths and/or to throw an exception rather than aborting when it fails to load. (The Qt folks seem to think that the location of qt.conf is not their problem. https://bugreports.qt.io/browse/QTBUG-58637) Not much we can do on our end short of hacks like fixqtpath.

[tkf]

Only mildly insane, but we are used to that.

🤣

The Qt folks seem to think that the location of qt.conf is not their problem. https://bugreports.qt.io/browse/QTBUG-58637

Reporting it to all four Python Qt bindings sounds like a nightmare... Especially if just a subset of them support it.

I guess the upside is that Qt team seems at least positive for solving the "root cause" https://bugreports.qt.io/browse/QTBUG-14150