Rpm for Fedora Extra

My preference is for 3 separate packages - matplotlib which

    > depends on dateutils and pytz.

    > I think the problem is caused by matplotlib itself. I don't
    > think that matplotlib should repackage dateutils and pytz
    > which are already independent packages. I understand that
    > John included them initially in order to make matplotlib
    > easier to download and install, which I understand. But now
    > that matplotlib is being packaged for distributions it
    > creates unnecessary extra work for the matplotlib
    > packagers.

I agree the situation is not ideal, but it is not just pytz and
dateutil that we a re talking about. It is also agg, pyparsing and
pycxx. I think we would turn a number of people off if we said, first
install Numeric, pycxx, agg, pytz, pyparsing, dateutil, freeytpe, png
and zlib. The current approach tries to balance the likelihood that a
prereq is already on the system with the ease of installation of that
package (do packages for the various platforms already exist?) with my
desire to simplify the build configure process by controlling which
version matplotlib uses. agg, for example, is particularly vexing,
because Maxim frequently updates a given release (agg23 for example)
w/o changing the version number even when the updates break existing
code. In this case, it is not sufficient even to say "use agg23".

Also, we have to balance inconvenience of package developers with
inconvenience of users. Given a choice, I tend to inconvenience the
power users, because they are more able and willing to deal with it.

That said, I think there is a compromise solution which may satisfy
everyone. Following Chris Barker's suggestion, we can create a zip
file or tarball of matplotlib deps, which has the src of all of the
prereqs (except python and numerix) in it, and rewrite the setup to
have a proper configure, checking for each prereq and issuing a kind
error like "you are missing the freetype prereq, please install it or
download http://someserver.com/mpldeps.zip and unzip it in this dir.
This would keep the matplotlib distro (and CVS updates) as light as
possible while making it easier to compile mpl on OSX and some linux
distros. Of course, to do this right requires a fair amount of
effort, but I am all for it. I worked for a while trying to use the
distutils configure functionality (which can test for include headers,
libs and the like) but was unsuccessful. The question that stumped me
was how to properly communicate the results of the config process to
the build process. I posted this to c.l.python but got no answer:
http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/97cbe06f5efa58c0/18a015cba8bf2bd0?q=author:jdhunter@...4…+group:comp.lang.python+distutils&rnum=1&hl=en#18a015cba8bf2bd0

If anyone wants to work on this, I'll be happy to help. But the
setup/configure/build process is fairly elaborate since it involves
multiple dependencies and gui toolkits across platforms, which is why
I have been a bit reluctant to refactor it.

JDH

[...]

Also, we have to balance inconvenience of package developers with
inconvenience of users. Given a choice, I tend to inconvenience the
power users, because they are more able and willing to deal with it.

Its not just a tradeoff between package developers and users because
if you make things easy for package developers you also make things
easier for users (who use those packages) since they are now able
to install from the package instead of using cvs or a tar or zip file.

That said, I think there is a compromise solution which may satisfy
everyone. Following Chris Barker's suggestion, we can create a zip
file or tarball of matplotlib deps, which has the src of all of the
prereqs (except python and numerix) in it, and rewrite the setup to
have a proper configure, checking for each prereq and issuing a kind
error like "you are missing the freetype prereq, please install it or
download http://someserver.com/mpldeps.zip and unzip it in this dir.
This would keep the matplotlib distro (and CVS updates) as light as
possible while making it easier to compile mpl on OSX and some linux
distros. Of course, to do this right requires a fair amount of
effort, but I am all for it. I worked for a while trying to use the
distutils configure functionality (which can test for include headers,
libs and the like) but was unsuccessful. The question that stumped me
was how to properly communicate the results of the config process to
the build process. I posted this to c.l.python but got no answer:
http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/97cbe06f5efa58c0/18a015cba8bf2bd0?q=author:jdhunter@...4…+group:comp.lang.python+distutils&rnum=1&hl=en#18a015cba8bf2bd0

A light cvs with a zipfile of dependencies seems like a good idea.

Maybe there was no response to the distutils question because nobody
knows how to do it, or because distutils is not powerful enough to
support it very well. Or just because nobody else writes Python packages
with as many dependencies as matplotlib!

The Python source code (and PyGTK) use gnu autotools (autoconf,
automake, etc) to configure and install themselves. Its more powerful
than distutils and is used by many C projects, but can be used for
Python too.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com

···

On Sat, 2005-07-02 at 09:59 -0500, John Hunter wrote: