Red Hat Bugzilla – Bug 1030396
default backend qt4agg not installed by default
Last modified: 2014-02-21 19:39:41 EST
Description of problem:
In f20, the default backend of matplotlib is qt4agg, but is not installed by default. Without a custom configuration in .config/matplotlibrc, a program using matplotlib will abort with ImportError: No module named backend_qt4agg unless python(3)-matplotlib-qt4 is installed.
Furthermore, the matplotlib includes the gtk backends. IMHO, thse should be moved to a different subpackage as they are not default.
Version-Release number of selected component (if applicable):
After installing python-matplotlib, the current "rawhide" tree also produces the error message "ImportError: No module named backend_qt4agg".
In a previous version of python-matplotlib, the default backend was defined differently, and that was:
backend : GTKAgg
Since GNOME is the default desktop of Fedora, the default should be reset to "GTKAgg" instead of keeping "" pulling in unwanted QT packages including required packages when installing python-matplotlib.
As a workaround, choosing "backend : GTKAgg" in .matplotlib/matplotlibrc restores proper working without installing python-matplotlib-qt4.
Btw, there is the stable bug fix release 1.3.1 which has not been adopted yet.
In future builds GTKAgg will be used again.
(In reply to Thomas Spura from comment #2)
> In future builds GTKAgg will be used again.
I disagree. If upstream has decided to favour QT4 over GTK we shouldn't change it. At least without asking upstream why they prefer one over the other.
"The Fedora Project focuses, as much as possible, on not deviating from upstream in the software it includes in the repository."
This is what Debian does:
$ cat debian/setup.cfg
# User-configurable options
# Default backend, one of: Agg, Cairo, CocoaAgg, GTK, GTKAgg,
# GTKCairo, FltkAgg, Pdf, Ps, QtAgg, Qt4Agg, SVG, TkAgg, WX, WXAgg.
# The Agg, Ps, Pdf and SVG backends do not require external
# dependencies. Do not choose GTK, GTKAgg, GTKCairo, TkAgg or WXAgg if
# you have disabled the relevent extension modules. Agg will be used
# by default.
backend = TkAgg
Most users would have installed GTK anyway, so I didn't want to pollute people with qt dependencies unless they choose themselves to do so.
IIRC, TkAgg was the default before matplotlib's upstream switched to GTKAgg ;)
(In reply to Sergio Pascual from comment #3)
> I disagree. If upstream has decided to favour QT4 over GTK we shouldn't
> change it. At least without asking upstream why they prefer one over the
Both backends are fully supported, which is why you are free to configure your choosen backend. If there are indeed problems with GTK, we can search for an alternative.
Until then, I'd vote for GTKAgg, because of the qt dependencies (I'm sure we'll get a bug soon, if we pollute qt into the whole distribution...)
(In reply to Thomas Spura from comment #5)
> Both backends are fully supported, which is why you are free to configure
> your choosen backend. If there are indeed problems with GTK, we can search
> for an alternative.
> Until then, I'd vote for GTKAgg, because of the qt dependencies (I'm sure
> we'll get a bug soon, if we pollute qt into the whole distribution...)
Pollute? In what sense is qt polluting the distribution? I have qt installed and I haven't noticed anything in my gnome desktop. And then, is polluting matplotlib the system of those poor guys and gals running kde? They cannot remove the gtk backend
Now seriously, if you are worried about the livecd, there's no matplotlib there. Who else is going to fill bugs?
I do not particularly prefer qt over gtk, in fact I prefer Debian's "agnostic" approach.
I'm quoting here the section of
relevant to this. Please change "MySQL" and "Postgres" by "Gtk", "QT", "Tk", etc and "database backend" by "ploting backend"
For instance, if a particular upstream software allows both MySQL as Postgres as a database backend, other distributions might have picked Postgres and Fedora package of that upstream software might be configured to use the MySQL backend by default instead. If upstream or other distributions are favoring one of the options over the others, talk to them, find out why and rely on well tested and consistent options as much as possible.
I would like to jump in on this bug also.
I understand what Sergio is saying about respecting upstream, however if Fedora 20 out of the box is configured for GTK then shouldn't the package set .config/matplotlib/matplotlibrc to use GTKAgg as backend? This is the difference between working out of the box and the user getting a cryptic error.
python-matplotlib-1.3.1-3.fc20 has been submitted as an update for Fedora 20.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing python-matplotlib-1.3.1-3.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
(In reply to Andrew Dunn from comment #7)
> I would like to jump in on this bug also.
> I understand what Sergio is saying about respecting upstream, however if
> Fedora 20 out of the box is configured for GTK then shouldn't the package
> set .config/matplotlib/matplotlibrc to use GTKAgg as backend? This is the
> difference between working out of the box and the user getting a cryptic
Unfortunately, we needed to switch to TkAgg now because python3 and GTK don't play well together... (Also see comment #4)
(In reply to Thomas Spura from comment #10)
In this case, WXAgg is clearly a better choice: it is visually very close to the GTKAgg backend, and WX widgets are already used by the gnuplot package.
(In reply to Christoph Frieben from comment #11)
> (In reply to Thomas Spura from comment #10)
> In this case, WXAgg is clearly a better choice: it is visually very close to
> the GTKAgg backend, and WX widgets are already used by the gnuplot package.
The WXAgg backend has the same problem as GTKAgg, that it
only works with python2. The options to work with python3
were Qt4Agg and TkAgg.
python-matplotlib-1.3.1-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.