Clean dependencies for Plots

General Usage
, ,
1

I have just upgraded to Julia 1.6. Looks nice. Rebuilt as many packages as I could (seems Julia errors out on some rebuilds).

I go back and forth between pyplot and gr as backends for Plots. Both have some bad side effects that don’t affect the plots but effect usage.

- pyplot()

┌ Warning: PyPlot is using tkagg backend, which is known to cause crashes on MacOS (#410); use the MPLBACKEND environment variable to request a different backend.
└ @ PyPlot ~/.julia/packages/PyPlot/XHEG0/src/init.jl:192
Plots.PyPlotBackend()

objc[37680]: Class RunLoopModeTracker is implemented in both /Users/lewislevin/.julia/artifacts/ee74d003b12e6dd5f748e8cefb1688edbdfb184b/lib/QtCore.framework/Versions/5/QtCore (0x15976aaa8) and /Users/lewislevin/opt/miniconda3/lib/libQt5Core.5.9.7.dylib (0x185486a80). One of the two will be used. Which one is undefined.
  • So, we have 2 instances of QT5 installed. I didn’t ask for that to happen, but there you go. Miniconda wants its own. GR wants its own. But, since in this case plots uses pyplot backend which runs PyPlot(?) or maybe uses pycall directly to call Matplotlib it should only be using the qt implementation that is part of conda Python.
  • Then it says that TkAgg is the backend. But, it’s not. My matplotlibrc shows the backend as Qt5Agg. to confirm see this:
julia> using PyPlot

julia> pygui()
:qt5
  • When I run PyPlot as the plotting package, the pygui and other commands confirm that a Qt5Agg is the backend. So, either Plots is wrong about what the Matplotlib backend really is–or it is ignoring the setting–which is hard to do because Plots itself doesn’t determine this, Matplotlib determines which backend it will use.
  • More interestingly, this backend side effect depends on order. If I make a plot using the gr() backend (or just let plots default to it) AND then switch to pyplot(), I see the side effects. But, if I immediately choose pyplot() before any plots with plot, neither side effect occurs.

gr()

  • On first use, this will present the warnings about which QT library is being used. In this case, the one associated with conda Python either can’t or should not be used because gr doesn’t ever call Python. It should be using the one in its own Julia binary artifact.
  • GR persistently shows the incoming network connections dialog on MacOS. This is a really ugly side effect. I have gone to settings security firewall in MacOS and set the allow network connections settings for gksqt.app to Deny. Shouldn’t that override being asked every time a plot window appears? I’ve read the advice on MacOS to delete the plist file for the offending app and let the settings get rebuilt, but I can’t find the plist file for gksterm.
2

OK! Fixed pyplot() backend running under Plots package. There are at least 2 locations for matplotlibrc for the Python env being used by my Julia installation. The “closest” one takes precedence sometimes and the farther one other times. That gave the inconsistency between pyplot() and Plots with pyplot backend. Set both matplotlibrc files to same backend and no problem.

3

Here is the “which library to use” warning for gr:

objc[38425]: Class RunLoopModeTracker is implemented in both /Users/lewislevin/opt/miniconda3/lib/libQt5Core.5.9.7.dylib (0x177071a80) and /Users/lewislevin/.julia/artifacts/ee74d003b12e6dd5f748e8cefb1688edbdfb184b/lib/QtCore.framework/Versions/5/QtCore (0x181610aa8). One of the two will be used. Which one is undefined.
objc[38425]: Class QCocoaPageLayoutDelegate is implemented in both /Users/lewislevin/opt/miniconda3/lib/libQt5PrintSupport.5.9.7.dylib (0x17c158ef0) and /Users/lewislevin/.julia/artifacts/ee74d003b12e6dd5f748e8cefb1688edbdfb184b/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport (0x18253e480). One of the two will be used. Which one is undefined.
objc[38425]: Class QCocoaPrintPanelDelegate is implemented in both /Users/lewislevin/opt/miniconda3/lib/libQt5PrintSupport.5.9.7.dylib (0x17c158f40) and /Users/lewislevin/.julia/artifacts/ee74d003b12e6dd5f748e8cefb1688edbdfb184b/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport (0x18253e4f8). One of the two will be used. Which one is undefined.
4

I’m getting the same Class RunLoopModeTracker is implemented in both... warning. Can you elaborate on your solution for me? Where are your two matplotlib files located? How did you tell them to use the same backend? Thanks!

5

Sorry. Just saw this.

It’s a bear to debug and fix this stuff.

I use Miniconda. The Julia crowd will tell you to install PyCall and it will download and install ALL of the Anaconda distribution of Python–a mere 4gb. I refuse to cart around that mess. A reasonable Python installation with matplotlib and bumpy should be around 400mb, though “Miniconda” is not so mini. It is 5.12gb, too, because of the binary support from Intel. It’s just a mess.

Right now there is a bug in Plots which I’ve reported in which it doesn’t pickup the correct backend for PyPlot even though Python itself and PyPlots package do by setting the environment variable in your .bashrc or .zshrc file: export MPLBACKEND=qt5agg.

But, with Plots broken at the moment I’d suggest either using gr() as the backend (the Plots default–works for most things except 3d plots) or just use PyPlot. It’s the most mature and robust plotting for Julia. Slightly more awkward API than plots but really solid.

Julia needs to focus everyone working on plotting one ONE THING and stop fragmenting the effort across 12+ solutions with essentially minor or arbitrary differences (snowball in Hades chance of this happening).

1 Like