cairo, qt, qt4, fltk, and wx use flags might be appropriate additions, and the tetex use flag should really be called "latex" now that texlive is in portage. Reproducible: Always
> cairo, qt, qt4, fltk, and wx use flags might be appropriate additions, and the > tetex use flag should really be called "latex" now that texlive is in portage. For wx, now that we have better support, I will reconsider implementing it. For cairo, qt*, fltk, are those enabled in the setup.cfg? There isn't much doc on how enabling/disabling them. As for tetex/latex use flag, it is being discussed now in the dev ml.
(In reply to comment #1) > For wx, now that we have better support, I will reconsider implementing it. For > cairo, qt*, fltk, are those enabled in the setup.cfg? There isn't much doc on > how enabling/disabling them. There is nothing to do. There are checks in setup.py or setupext.py, so extension code is built in the case of wx, gtk, and maybe tk if the appropriate libraries are installed. I dont think extension code is needed with wx 2.8. No extension code is required for qt* or fltk. I think adding RDEPENDS for PyQt, PyQt4, wxpython, fltk, and pycairo should be sufficient, matplotlib will take care of the rest.
I took a deeper look. In DEPENDS, it would need: +wxwidgets to build wxpython bindings, with patch similar to gtk IN RDEPENDS, it will need +cairo to add pycairo deps +qt3 to add PyQt +qt4 to add PyQt4 +fltk would need pyFltk which is not in portage. Now I am not sure the cairo, qt* and fltk ones are really useful. matplotlib does not need them to run, the installed matplotlib seems to be identical whether they are installed or not. Basically it just helps the user to tell him such backends exist. Also, emf, paint and gd backend are presents. Wouldn't the pyemf, pypaint and gdmodule deps be needed in the same vein? That would adds quite a few use flags then.
(In reply to comment #3) > I took a deeper look. > In DEPENDS, it would need: > +wxwidgets to build wxpython bindings, with patch similar to gtk > > IN RDEPENDS, it will need > +cairo to add pycairo deps > +qt3 to add PyQt > +qt4 to add PyQt4 > > +fltk would need pyFltk which is not in portage. > > Now I am not sure the cairo, qt* and fltk ones are really useful. matplotlib > does not need them to run, the installed matplotlib seems to be identical > whether they are installed or not. Basically it just helps the user to tell him > such backends exist. ... and to manage the dependencies if the user desires to use that backend. > Also, emf, paint and gd backend are presents. Wouldn't the pyemf, pypaint and > gdmodule deps be needed in the same vein? That would adds quite a few use flags > then. You are right about emf, but I don't think we have a paint backend anymore, and we dont use gdmodule. Future releases may not include the emf and gdk backends.
Hi Darren, I added an experimental matplotlib-0.91.1 in the science overlay, taking care of these use flags. The setup changed a bit, so let me know what you think and I'll commit it to the main tree soon.
(In reply to comment #5) > Hi Darren, > > I added an experimental matplotlib-0.91.1 in the science overlay, taking care > of these use flags. The setup changed a bit, so let me know what you think and > I'll commit it to the main tree soon. Thank you for doing this. I suggest adding poppler to the list of latex? RDEPENDS. Matplotlib can use poppler's pdftops to "filter" its postscript output, generating high-level ps or eps files with true fonts and searchable text. Ghostscript can also be used to distill the latex output, but produces low-level postscript. (Filtering is necessary because the psfrag package we use includes illegal operators in the eps files, a big problem for creating publication-quality graphics for scientific journals.) Also, I think the gentoo ebuild should prevent matplotlib from providing enthought.traits. Traits is not used, not yet. Here's a diff: Index: /usr/portage/local/layman/science/dev-python/matplotlib/matplotlib-0.91.1.ebuild =================================================================== --- /usr/portage/local/layman/science/dev-python/matplotlib/matplotlib-0.91.1.ebuild (revision 848) +++ /usr/portage/local/layman/science/dev-python/matplotlib/matplotlib-0.91.1.ebuild (working copy) @@ -30,7 +30,8 @@ media-fonts/ttf-bitstream-vera latex? ( virtual/latex-base virtual/ghostscript - app-text/dvipng ) + app-text/dvipng + app-text/poppler ) cairo? ( dev-python/pycairo ) fltk? ( dev-python/pyfltk ) qt3? ( dev-python/PyQt ) @@ -64,6 +65,7 @@ echo "pytz = False" echo "dateutil = False" echo "configobj = False" + echo "enthought.traits = False" echo "[gui_support]" use_setup gtk use_setup tk Please hold off though, 0.91.1 is not ready to go. There are a few files that didn't make it into the src tarball, so backend_driver.py (which we use to test for breakage) is throwing a fit. More soon...
(In reply to comment #6) > Please hold off though, 0.91.1 is not ready to go. There are a few files that > didn't make it into the src tarball, so backend_driver.py (which we use to test > for breakage) is throwing a fit. More soon... I just retested, and it looks like the above comment was in error. backend_driver runs without errors. I did notice another error though, which does not occur during a regular "python setup.py build" procedure: Xlib: connection to ":0.0" refused by server Xlib: No protocol specified Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4 wxPython: 2.6.4.0 Xlib: connection to ":0.0" refused by server Xlib: No protocol specified /usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py:72: GtkWarning: could not open display warnings.warn(str(e), _gtk.Warning)
Thanks for following up! I added your patch in comment #6. > I just retested, and it looks like the above comment was in error. > backend_driver runs without errors. So if I understand, 0.91.1 is upstream ready. > Xlib: connection to ":0.0" refused by server > Xlib: No protocol specified This was caused by "import gtk" and "tk = Tkinter.tk()" in the setupext.py. I added a sed that avoid such checks in the ebuild, but you might consider fixing the check_for_gtk and check_for_tk avoiding the needs of display. Also few other questions I noticed while cleaning the ebuild. * How about fonts: which ones can we remove safely and put as dependencies? * Are you guys upstream considering putting the matplotlib files in standard FHS directories? config files in /etc and mpl-data in /usr/share/matplotlib? It could be some directory option in the setup.cfg. * there are left over .cvsignore you might want to remove from the tar ball
(In reply to comment #8) > So if I understand, 0.91.1 is upstream ready. Correct. > > Xlib: connection to ":0.0" refused by server > > Xlib: No protocol specified > > This was caused by "import gtk" and "tk = Tkinter.tk()" in the setupext.py. I > added a sed that avoid such checks in the ebuild, but you might consider fixing > the check_for_gtk and check_for_tk avoiding the needs of display. I don't know how that would be done. > Also few other questions I noticed while cleaning the ebuild. > * How about fonts: which ones can we remove safely and put as dependencies? I guess the Vera fonts could be removed. Maybe it would be appropriate to require ttf-bitstream-vera in DEPENDS, since these are the default? texcm-ttf does not provide cmb10.ttf, cms10.ttf, or cmtt10.ttf, all of which ship with mpl, so the computer modern fonts cannot be removed at this time. There is an ebuild request for the stix fonts at http://bugs.gentoo.org/show_bug.cgi?id=197841, so when that hits portage the stix fonts could be removed. > * Are you guys upstream considering putting the matplotlib files in standard > FHS directories? config files in /etc and mpl-data in /usr/share/matplotlib? It > could be some directory option in the setup.cfg. It used to be done that way (except for config files in /etc), but was changed to support setuptools and eggs. I don't understand gentoo's policy of requiring setuptools (http://bugs.gentoo.org/show_bug.cgi?id=197632), and my inquiries have not been answered. So I don't feel compelled to address the issue of where mpl-data gets installed. I agree that the config files should go in /etc. Maybe this can be improved in a future release. > * there are left over .cvsignore you might want to remove from the tar ball I'll look into it. Thanks.
Concerning the FHS, I don't know much about setuptools. python herd, ping, see comment #9. I updated again the ebuild in the overlay. Left over are removed, and added the stix and bakoma licenses. Also try to respect FHS with seds. The ebuild should be ready to hit the tree.
now in portage. Thanks for your help Darren.
