Hi guys,
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,
···
On Fri, May 29, 2009 at 11:51, Daniel Watkins <daniel@...723...> wrote:
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
I've found pyparsing rather brittle between revisions in the past, hence the desire to have a local copy. I don't know if recent versions have stabilized -- given that we have something that works, I'm not too keen on tinkering with it.
Not knowing much about packaging myself, I think Debian should only go forward with using an external dependency if an *exact* version of pyparsing can be specified, rather than >=. Or at the very least, if a different version of pyparsing is applied, one needs to make sure that the mathtext examples all pass unchanged.
Mike
Sandro Tosi wrote:
···
Hi guys,
On Fri, May 29, 2009 at 11:51, Daniel Watkins > <daniel@...723...> 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,
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA