On Sat, Nov 1, 2008 at 5:37 AM, Sandro Tosi <[EMAIL PROTECTED]> wrote: > Hello guys! > Following up the discussion Benjiamin and me had about a couple of > bugs in Ubuntu[1] and Debian[2], and what Mike wrote on [1], we'd like > to explore the possibility for you to develop a "backend=Auto" mode, > that can discover automatically at runtime the backend to use from the > ones available (in case of multiple backends, let's use a priority > list [gtk, qt, tk, ...]).
This should be fairly easy to implement -- we already do something like this at build time when we choose the default backend to put into the template. FYI, since you are a packager, I jwant to clarify what happens at build time. We have a file called setup.cfg.template which is a template for people who want to override the default behavior. You can copy this to setup.cfg and choose what default backend you want, and the setup program will create an rc configured accordingly. But if someone has not done this, the setup script will look (at build time) for gtk, wx, and tk, and set the backend in order of increasing preference: Agg, TkAgg, WXAgg, GTKAgg. The file matplotlibrc.template is then used to generate the default matplotlibrc, with this backend selected. This matplotlibrc is installed to matplotlib/mpl-data/ and is used as the default config if the user does not override it. As a debian/ubuntu packager, you will probably want to use setup.cfg and set your backend manually. You may want to use TkAgg since in some ways this is the simplest backend to use in the most contexts, primarily because it does not require special threading calls to work interactively in the python shell -- see http://matplotlib.sf.net/installing.html But an "Auto" feature would be useful in other contexts too. One area is when matplotlib is embedded in a GUI IDE matlab-like application. There are several of these that are being worked on in different user interfaces, primarily using the new embeddable ipython, and the concern there is that the user may be using one application which embeds a python shell, and when users import pylab in that shell, the ought not to have to think: "now I am using python in a wx app, so I need to sert wxagg" but in other scenarios, "now I am using pylab in a plain python shell so use tkagg" The auto search algorithm should go something like the following: * if tkinter, wx, gtk or qt has already been imported in sys.modules, use that backend - Gael has already an implementation in the pyplot module using the rc param 'backend_fallback' * if backend = 'auto': try in order of preference :tkagg (most likely to work in most contexts), gtkagg, wxagg, qtagg. This order could easily be configurable * if none of the UIs are available in 'auto' mode, issue a warning and set 'agg' If I were packaging for ubuntu, I would select tkagg as the default, so you don't have to wade into the GNOME vs KDE arena and because it works out of the box in the most contexts and is a pretty small dependency. You could modify the matplotlib runtime so that when the .matplotlib directory is created (the first time mpl is run) it issues a message like Creating config directory ~/.matplotlib. The default user interface toolkit for matplotlib is TkInter via the "TkAgg backend" (see http://matplotlib.sourceforge.net/faq/installing_faq.html#id1). You use other backends, you will need to install additional ubuntu dependencies. For GTKAgg, install python-gtk, for WXAgg, install python-wxgtk, etc..." > Personally, I think we can even attack the problem with a different > solution: continue to ship all the mpl file in the "main" package > (python-matplotlib in Debian & Ubuntu) and then create some "dummy" > packages that simply depends on the python gui bindings (let's call > them python-matplotlib-<ui>), each of them providing a virtual > package, let's call it python-matplotlib-backend. If python-matplotlib > depends on python-matplotlib-gtk OR python-matplotlib-backend, any > backend installed can satisfy that dependency (and the default being > gtk). That should work fine, but I advise installing all of mpl and use these dummies only for dependencies. > Both of them has cons: the first poses problem to us for the > packaging, and both does not solve the problem of not choosing a > default (or requiring to specify another package (the backend chosen) > when installing python-matplotlib); moreover, what other packages > depending on python-matplotlib should do after this change (they > expect mpl to Just Work)? Well, if the package that depends on mpl requires for example wx and the wx backend, then it is enough for them to get a full mpl install and handle the wx dependency in their package. They would need to make sure that the right mpl backend is selected when they import mpl, but they can do that with the use directive. > Another solution (that would save the most of the current work done), > almost the same currently used today is: keep doing the same thing as > of now, but do not install any python gui bindings, but popup a > windows at python-matplotlib install time to ask the user what binding > to use (then create the ad-hoc /etc/matplotlirc file with that > "backend" set) and then ask to install the correct python binding for > the backend chosen. A light version is: keep choosing gtk as default > backend, and clearly document (even at install time) how to change > backend. This is in line with what I was suggesting, though I was suggesting it at mpl first run time. Either way could work. I do see that this is a problem: a colleague of mine with a new ubuntu 8.10 box installed python-matplotlib as one of his first packages, and it brought in 280 MB of packages, including several UI toolkits and a full tex distribution. I think the packagers are being over inclusive. For optional dependencies like usetex, which most people do not use, and optional backends, it would be better to have a clear set of instructions for users who want these optional features to simply apt-get install the optional dependencies themselves. JDH ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
