Hi guys,

On Fri, May 29, 2009 at 11:51, Daniel Watkins
<dan...@daniel-watkins.co.uk> wrote:
> Package: python-matplotlib
> Version: 0.98.3-5
> Severity: normal
>
> python-matplotlib installs its own copy of pyparsing.py when it should
> in fact be using the copy that is shipped in python-pyparsing.

We've just receive this bug report about the internal copy of
pyparsing included in mpl.

The situation in Debian is:

Stable            1.5.0-1
Testing         1.5.1-2
Unstable        1.5.2-1

Currently mpl ship:

$ grep "^__version" lib/matplotlib/pyparsing.py
__version__ = "1.5.0"
__versionTime__ = "28 May 2008 10:05"

In the changelog I can see:

$ egrep -A2 "2007-11-09.*pyparsing" CHANGELOG
2007-11-09 Moved pyparsing back into matplotlib namespace. Don't use
           system pyparsing, API is too variable from one release
           to the next - DSD

So there seems to be a reason for this "private" copy. The question
is: is this reason still valid nowdays? should we (at least packagers)
remove the private copy and rely on the system pyparsing (or at least
introduce a "check if system has pyparsing, if not fallback on
private" wrap)?

I haven't checked, but maybe you already know the answer :)

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to