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, ...]).
Our main goal, as packagers, is to avoid the installation of gnome dependencies (gtk2 is now the default in both sid and lenny-near-to-be-stable, for Ubuntu is tk) for kde users (and viceversa, or any other combination). One way is to ship a "core" package, that contains the main functionalities, and some "backend" packages to depends (or even contains the real backend files, like .so & altera) on the available gui python bindings. Related to the above sentence, is this question: how easy is to "split" backend files? is it enough to separate files under /usr/lib/python*/site-packages/matplotlib/backends/* in different packages? But that would only create 3 pkgs: agg, gtk and tk. What about wx and qt? 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). 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)? 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. What you (upstream and distribution packages users) expect from us (packagers) about these 2 questions (backend=Auto and multi backend support)? Of course, any suggestion is very welcome :) Thanks in advance, Sandro [1] https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/278764 [2] http://bugs.debian.org/502976 -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ------------------------------------------------------------------------- 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
