Bug 1030396 - default backend qt4agg not installed by default
default backend qt4agg not installed by default
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: python-matplotlib (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Thomas Spura
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-14 06:16 EST by Sergio Pascual
Modified: 2014-02-21 19:39 EST (History)
7 users (show)

See Also:
Fixed In Version: python-matplotlib-1.3.1-3.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-21 19:39:41 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sergio Pascual 2013-11-14 06:16:23 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):
python-matplotlib-1.3.0-1.fc20.x86_64
python3-matplotlib-1.3.0-1.fc20.x86_64
Comment 1 Joachim Frieben 2014-01-25 08:42:31 EST
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.
Comment 2 Thomas Spura 2014-01-25 10:33:46 EST
In future builds GTKAgg will be used again.
Comment 3 Sergio Pascual 2014-01-26 18:54:48 EST
(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."

http://fedoraproject.org/wiki/Staying_close_to_upstream_projects
Comment 4 Paulo Andrade 2014-01-27 12:06:28 EST
This is what Debian does:

$ cat debian/setup.cfg
[rc_options]
# 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
Comment 5 Thomas Spura 2014-01-28 02:50:44 EST
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
> other.

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...)
Comment 6 Sergio Pascual 2014-01-28 05:10:11 EST
(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 

http://fedoraproject.org/wiki/Staying_close_to_upstream_projects

relevant to this. Please change "MySQL" and "Postgres" by "Gtk", "QT", "Tk", etc and "database backend" by "ploting backend"

"""
Configuration options
    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. 
"""
Comment 7 Andrew Dunn 2014-02-02 10:47:24 EST
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.
Comment 8 Fedora Update System 2014-02-11 11:20:12 EST
python-matplotlib-1.3.1-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/python-matplotlib-1.3.1-3.fc20
Comment 9 Fedora Update System 2014-02-12 09:39:20 EST
Package python-matplotlib-1.3.1-3.fc20:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2014-2352/python-matplotlib-1.3.1-3.fc20
then log in and leave karma (feedback).
Comment 10 Thomas Spura 2014-02-12 09:42:32 EST
(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
> error.

+1

Unfortunately, we needed to switch to TkAgg now because python3 and GTK don't play well together... (Also see comment #4)
Comment 11 Joachim Frieben 2014-02-15 13:53:03 EST
(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.
Comment 12 Paulo Andrade 2014-02-19 13:45:25 EST
(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.
Comment 13 Fedora Update System 2014-02-21 19:39:41 EST
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.

Note You need to log in before you can comment on or make changes to this bug.