Request for review: pytz and python-dateutil

Orion Poplawski orion at cora.nwra.com
Wed Jul 6 15:30:47 UTC 2005


José Matos wrote:
> Orion Poplawski wrote:
> 
>   Hi,
> 
> 
>>I'm attempting to shift my python-matplotlib package to use upstream
>>versions of pytz and dateutil.  It bundles a version of each with it,
>>but will not install if already present.  So, it seems best to provide
>>official versions of pytz and python-dateutil and have python-matplotlib
>>require these to be present at build.
> 
> 
>   Last friday I sent a message to matplot-users list asking for the author
> opinion on this subject. In one of the replies John Hunter, matplotlib
> maintainer, said that matplotlib tar ball has several others python modules
> inside:
> 
>   - agg
>   - pyparsing
>   - pycxx
> 
>   I will review later both pytz and python-dateutil packages.
> 

Yeah, matplotlib is one big mess of a bunch of packages smashed 
together.  At least with pytz and datetutil though, setup.py detects 
their presence and does not install if present.  This was actually 
causing me grief when I tried to rebuild my python-matplotlib rpm with a 
version already installed.  This is what motivated me to explicitly 
require pytz and python-dateutil - to obtain reproducible builds.

agg, pyparsing, and pycxx are more tightly integrated, install in the 
matplotlib directory, and are referred to like:

from matplotlib.pyparsing import Literal, Word, OneOrMore, ZeroOrMore, \
      Combine, Group, Optional, Forward, NotAny, alphas, nums, alphanums, \
      StringStart, StringEnd, ParseException

(i.e. in the matplotlib namespace).

I personally am not interested in doing the work of splitting matplotlib 
up, though I think the upstream project should do so.  All this bundling 
is just a PITA in my opinion.

There is similar issues with basemap, a matplotlib toolkit that I want 
to package.  It bundles a version of PROJ.4.  The maintainer though 
warned me against using an external PROJ.4 library.  Again, it installs 
in its own space, so I don't have a big issue with it, but it strikes me 
as against the whole point of having common libraries.

Other opinions on this welcomed, and I'm happy to go with whatever 
consensus develops.

- Orion



-- 
Orion Poplawski
System Administrator                   303-415-9701 x222
Colorado Research Associates/NWRA      FAX: 303-415-9702
3380 Mitchell Lane, Boulder CO 80301   http://www.co-ra.com




More information about the fedora-extras-list mailing list