matplotlib-0.98.5.2-r2 is unable to create labels for semilog and log-log axes. According to the matplotlib maintainers, they bundle a specific version of pyparsing.py with matplotlib because certain parts of matplotlib are sensitive to small changes in pyparsing. Bug 252947 requested that the "bundled" versions of pycxx, pyparsing, and fonts be removed, which was implemented in matplotlib-0.98.5.2-r1. Since this was done, various parts of matplotlib have stopped working (see bug 256256) and matplotlib-0.98.5.2-r2 was released fix it. Now I am reporting that another part of Matplotlib is broken. I suggest that we revert to using the bundled version of pyparsing, and check with the matplotlib developers to see if they had equally good reasons to bundle specific versions of pycxx and fonts. Otherwise, we will constantly be chasing bugs like this one. Although it's not elegant to bundle "redundant" modules, the files in question are rather small and our time is valuable. For reference: http://sourceforge.net/mailarchive/forum.php?thread_name=49A2B762.8090600%40stsci.edu&forum_name=matplotlib-users
(I am one of the main matplotlib developers adding my 2c -- I'm not a Gentoo user). pyparsing does not have a very formal release process about API changes and small changes like this have bitten us in the past. One could argue, that as a single file it is really designed to be embedded within applications (as matplotlib does) and not to be used as a system-wide shared resource in most cases. Not using the matplotlib-included pyparsing.py is a show-stopper bug for anyone using math text on their plots. As for fonts -- please be certain that the fonts you replace with are true supersets of the fonts included in matplotlib. Vera/DejaVu fonts, for instance, are still a moving target, and many of the versions in the wild do not have all of the glyphs included in matplotlib. Loading the fonts in fontforge can help to verify this. The STIX fonts in matplotlib have been converted from otf to ttf by yours truly, and I'm not aware of any similar TTF versions elsewhere. Again, just ensure that the replacement systems files are identical or are supersets of what is in matplotlib. As for CXX, that is a slower-moving package, and I don't anticipate as many issues there. But that comes to my last point: Please test. matplotlib has a basic regression testing framework in examples/tests/backend_driver.py. Running that would have caught this issue immediately. SVN trunk (and future released versions) will also have nose-based tests in test/ as well.
Maybe a bit unrelated question, but anyone know if stix-font is still alive upstream, cause since they've released the beta, they've been awfully quiet. Their planned release date was months ago and there's nothing new on the webpage.
Hi, Thanks for reporting and thanks to Michael for th clarifications, I've been able to test it more and will commit soon a revised matplotlib ebuild. Here are my findings: * pycxx: system one is ok. * pyparsing: matplotlib bundled one is basically upstream pyparsing-1.5.0 with a very light modification, while . Why not proposing the small changes to pyparsing developers? G * fonts: I only use matplotlib occasionally, and I'm no font expert. So far, I see that stix-fonts ttf are indeed not supplied by system stix fonts. Are they necessary for matplotlib to work? Are they replaceable by some other fonts, more supported and used system-wide (matplotlib bundles in 3.4Mb of fonts)? * agg: I'm adding it here since we'are at it. Why does matplotlib force its own building of agg? Couldn't we use the system one (which is at 2.5 btw)? Bundling libraries is rarely a good idea. This makes it harder to maintain, has possible security/licensing issues, duplicates code, and goes against many distributions policies. See http://blog.flameeyes.eu/2009/01/02/bundling-libraries-for-despair-and-insecurity for long but good reasons of why not bundling. Michael, do you thing it would be possible for matplotlib to make it optional to use system libs or fonts in the [provide_packages] section, just like pytz and others?
* pyparsing: The changes in matplotlib's copy have already been sent upstream to pyparsing, but a pyparsing release has not been made since. Interesting to look at the differences, because they are trivial enough that I'm not sure how it explains the original poster's bug. What version of pyparsing does gentoo currently ship? (and excuse my Gentoo ignorance...) I think we need to get to the bottom of the source of the breakage before we can determine how to proceed. Though pyparsing has been a long-running thorn, as we get user's with "broken matplotlib" every time Ubuntu or Fedora or Gentoo puts out a new release. I mostly agree with your argument about not bundling, but that assumes a very careful approach to API breakage, which pyparsing (and honestly matplotlib) doesn't really have. * As for fonts -- the matplotlib font engine can only handle ttf, not otf fonts. The STIX fonts are distributed upstream as otf, and we convert them to ttf ourselves. If the system-wide package also had ttf versions, we would be ok. These fonts are required to support all of the math-rendering features in matplotlib. Not everyone uses that, but we don't currently have a mechanism to warn when the fonts aren't available that a certain feature won't be available. It's sort of tricky to do so given that matplotlib assumes its self-distributed fonts are always available. * As for Agg, we can't use 2.5 since it is licensed under the GPL (not BSD or even LGPL). From a technical perspective, not using the system library makes little difference -- it is primarily implemented in templatized C++ code that would get compiled into matplotlib anyway.
> it explains the original poster's bug. What version of pyparsing does gentoo > currently ship? (and excuse my Gentoo ignorance...) pyparsing >= 1.5.1 is the current dependency for matplotlib in Gentoo right now. * fonts: I will not remove the STIX again until there is some other solution. What about the other fonts: - mpl-data/fonts/ttf/Vera*.ttf: dejavu-2.28 should be ok - mpl-data/fonts/ttf/cm*.ttf: are they necessary? - mpl-data/fonts/{afm,pdfcore}: They can be provided by texlive and liberation-fonts This is quite helpful. Thanks. I've been able to pass all the backend_driver.py.
- mpl-data/fonts/ttf/cm*.ttf: are they necessary? Yes. They are also used for mathematical text in the LaTeX-lookalike mode. These are the "Bakoma" fonts, which you may already have a package for. Does the pyparsing 1.5.1 in Gentoo pass the backend_driver.py tests? If so, great, but we still haven't determined then why it failed for the OP.
matplotlib-0.98.5.2-r3 is now in the tree, with bundled pyparsing and stix-fonts, regression tests on backend_driver.py, and some other changes worth doing a new revision. Thanks all for the input. Hopefully the situation with bundled packages will get better in the future.
Many thanks to both of you!
