Re: [matplotlib-devel] Re: proposal: move py library code into lib subdir

[John H. <jdh...@ac...>]

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> My view is that a software package should not distribute
    Steve> and install its own dependencies.  I think matplotlib
    Steve> should have a list of dependencies (Python 2.2+, Numeric or
    Steve> numarray, ...) which it requires before it attempts an
    Steve> install, and a list of optional dependencies (pytz,
    Steve> dateutil, ...) which matplotlib supports if it finds they
    Steve> are already installed.

What's your argument for this?

My motivation to include them is mainly to simplify the install
process, to have some control over versioning, and to simplify the
coding process.  Since these are pure python packages, they present no
extra installation overhead for matplotlib and the only downside I see
is potential package bloat.  Both of these packages combined add 200k
to the src distro.  The coding burden is reduced, if for example I
know pytz is included, because I don't have to do a lot of conditional
stuff throughout the code where that module is used.

Does your opinion change for the win32 installer?  In that case, we
also include freetype, libpng, zlib.  I guarantee the numbers of win32
users would drop significantly if they had to install these extra
packages.  Neither dateutil nor pytz distribute a win32 installer.
dateutil doesn't include a zip file (only a tar.bz file).  So win32
users would first have to get bunzip2, and then tar, figure out how to
use them, install, etc, just to get matplotlib date support.

Basically, my goal is to maximize the likelihood that someone can use
matplotlib even if they haven't RTFM.  I wish they would read the
install instructions and dependencies, but I think that is only about
half of the users.  If we can set it up so that most things work out
of the box on a standard python setup - and I think having
Numeric/numarray) is fairly standard for most potential matplotlib
users.  

On a related note, Todd just added a fix in CVS that autodetects
numerix at build time and builds in Numeric and/or numarray.  It would
probably be a good idea to have an rc template and write the actual rc
file depending on what the autodetect finds in setup.py.  Eg, if setup
finds Tkinter and numarray but not pygtk and Numeric, there's not much
sense in using the default backend : GTKAgg and numerix : Numeric in
rc.  Paul did something like this for the license, so that the license
file was automatically built with the correct version number at build
time.


JDH