[intrepid] No output in ipython because because of wrong default backend

It was changed to go back to the upstream default. GTKAgg is also not DE-neutral so brings in a lot of dependencies by-default for KDE users, and also had some issues so it was decided to use the matplotlib default. People can easily change the backend so we're just trying to get a decent default.

Ok, I understand.

But "ipython -pylab" should" just work", or at least state prominently that you have to change the backend. A (not so linux adept) co-worker of mine dropped intrepid and installed hardy because of this. It took me >15 min to understand what's going on -- it did not feel ubuntu when I had to change a config file before I could work with the package.

matplotlib seems to pull Tk as dependency -- could "TkAgg" be a decent default?

Agg as an default doesn't even work in a python (read: normal "$ python" shell) interactive session. I use TkAgg in the moment.

(I'm an upstream developer).

Agg is the upstream default *only* if none of the GUI backends are installed (pygtk, PyQt, wxPython, or Tkinter). It's really a failsafe case, not a default.

I would suggest making python-tk a hard dependency and setting TkAgg as the default.

To address Joerg's suggestion -- it might be worth issuing a warning when "ipython -pylab" is started with a non-GUI backend. We can try to address that upstream, and I'll also submit a patch to this bug so it could be backported to 0.98.x

Attached a patch to display warning when user calls show() with non-GUI backend. This addresses Joerg's difficulty -- that it's hard to know what's wrong when matplotlib is mis-configured to not show a window.

This patch can be considered optional. The real bug here is that matplotlib is misconfigured to use a non-GUI backend as the default.

Here's a better patch that will only warn when show() is run directly from the python or ipython consoles.

I just tried the patch by Mike Droettboom.

It indeed does show a warning if I run python in the 'normal python console.

But if I run a file like the one below, I don't get any output nor a warning.
matplotlib in this way does seem to be broken if the default install doens't produce output for any of the simple examples in the tutorials. An indication what to fix would be less bad, but I feel that the default install should 'just work'.

#!/usr/bin/python
import pylab
pylab.plot(range(10), [i*i for i in range(10)])
pylab.show()

Since python-matplotlib pulls python-tk as dependency, I do not understand why "TkAgg" can't be the default.
Its much better than the current situation, where it just feels broken.

@joosteto: What you are seeing is the correct behavior, since the examples are designed to be interactive examples, and when no GUI backend is specified, there's not much matplotlib can do. The warning is not displayed in this case, because scripts that want to output a file usually have both show() and savefig(), and in that case warning on show() would be unnecessary noise. I think the fix that we're all clamoring for -- to have TkAgg be the default backend -- would address your concerns. Is that the case?

@Joerg: You and I are in full agreement. Hopefully the packager will make that change.

For some reason I thought I was subscribed to this bug but I wasn't. So as the guy who reverted the backend from GTKAgg to the upstream default (Agg) I have to admit that I didn't fully understand that Agg wasn't a GUI backend. I've always used GTKAgg, so my bad there.

What I was trying to get around was having so many Gnome/GTK dependencies by default for the KDE/Qt users. So the immediate thing we can do is make TkAgg the default backend (I thought it was actually in Debian). For Jaunty I'm thinking that maybe we should work on creating python-matplotlib-gtk and python-matplotlib-qt metapackages that would allow people to avoid pulling in a lot of deps they don't want.

Fantastic! Thank you!

Longer term, I think the metapackage idea has some promise. An alternative might also be for matplotlib to be more dynamic at startup time when selecting a backend. For example, we could have an "Auto" backend setting, that would select from Qt, Gtk, Tk, Cocoa etc. based on the user's DE and what is available and installed. Currently, we do this at build time, but it might be more appropriate at startup time in the context of pre-compiled packages. Anyway, that's OT for this bug, but we'd be happy to discuss this on the matplotlib-devel mailing list. Input from people with experience distributing things or who know how other projects handle this issue would be very helpful to us.

This bug was fixed in the package matplotlib - 0.98.3-4ubuntu1

---------------
matplotlib (0.98.3-4ubuntu1) intrepid; urgency=low

  * Merge from Debian unstable, remaining changes:
    - debian/control
      + replace wxgtk2.6 with wxgtk2.8
      + add python-pkg-resources dependency
  * debian/patches/default_backend:
    - added to set the default backend to TkAgg (Closes LP: #278764)
  * debian/control: move python-tk to default of binary backend deps

matplotlib (0.98.3-4) unstable; urgency=low

  [ Sandro Tosi ]
  * Release in collaboration with Benjamin Drung, from Ubuntu
  * debian/control
    - applied Benjamin Drung patch to split dep fields a package per line;
      thanks to him; Closes: #495287
    - replaced dep on python-dev with python; thanks to Benjamin Drung for the
      notice
    - depends reorganization: dvipng moved to recommends (optional tex
      depends), python-configobj and python-enthought-traits to suggests
      (experimental support); Closes: #490992
    - added python-matplotlib-dbg package and python-all-dbg, python-numpy-dbg
      to build-dep
    - removed python-gd depends since no more needed
  * debian/README.debian
    - removed outdated info, added notice for MATPLOTLIBDATA env variable
  * debian/python-matplotlib-data.install
    - added matplotlib.conf installation
  * debian/patches/matplotlibrc_fix.patch
    - refreshed to match new upstream code
  * debian/rules
    - added build, clean and install for -dbg package

  [ Ondrej Certik ]
  * debian/patches/build_fix.patch updated thanks to Thiemo Seufer.
      Closes: #501618

 -- Jordan Mantha <email address hidden> Tue, 14 Oct 2008 13:40:01 -0700

Thanks!
Yes, with the new package installed (with working backend) pylab/matplotlib again works the way I expect it to.