Request for review: pytz and python-dateutil

[José Matos]

Orion Poplawski wrote:

> 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.

  I had the same problem before. :-)

  I think also that those packages are a good starting point to disentangle
matplotlib knots. ;-)

  The important think is that the developers are aware of this issue and
they intend to fix. Not immediately but there is no hurry. :-)

> 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).

  Usually if the live in an independent namespace then it is easy to fix the
dependency. I did not look to the code in question so take my this as my
personal opinion. :-)

> 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.

  They had their reasons and I respect them. I remember the versions when
they introduced dateutils and pytz dependencies. Time to search for them,
to package and so on. If I was a user searching for a plot package I would
forget and pass to the next candidate.

  For some of the packages sometimes the API changes even without changing
the version. So unless you know and you are ready to deal with all the
changes it becomes difficult to take this without lots of code (therefore
with more bugs). It is always a tradeoff and sometimes there isn't an easy
answer.

  Now remember also that matplotlib supports several toolkits and several
platforms, it becomes really difficult to deal with the complexity
associated with its dependency.

  After the last messages to the list the developers are now aware of the
problems and they wish to fix it. That is good and I am happy that talking
it is possible to solve most of the issues that we as packagers face. :-)

> 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.

  Let us place this problems upstream and wait for an answer. The developers
are friendly and very helpful.

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

PS: Notice that matplotlib 0.83 was released today. :-)

-- 
José Abílio