proposal: move py library code into lib subdir

Development matplotlib-devel
1

My view is that a software package should not distribute

    > and install its own dependencies. I think matplotlib
    > should have a list of dependencies (Python 2.2+, Numeric or
    > numarray, ...) which it requires before it attempts an
    > install, and a list of optional dependencies (pytz,
    > dateutil, ...) which matplotlib supports if it finds they
    > 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

2

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

What's your argument for this?

My argument is that most other software I've looked at does this and it
seems to work OK. I guess the reasons are that
- it makes software packages smaller
- you only need to directly download one copy of a package and do not
indirectly download multiple copies of the same package.
- you can end up with multiple versions of a package. And later you may
try to recall - which package x did I use to install package y?
- the software package that includes other packages needs to make sure
it keeps up to date with with the included packages and does not install
old versions.

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

Yes, this is an advantage of including everything, and a disadvantage
for minimal packages.

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.

Win32 could be a special case.

As a way to encourage more users how about working towards moving from
the development status of version 0.62.4 "4 - Beta" to 1.0.0 "5 -
Production/Stable".
What's the criteria for this step?
My understanding is that it does not mean that all desired features are
implemented or complete, it just means that the software is stable, and
matplotlib seems to be pretty stable already.

Regards,
Steve

···

On Tue, 2004-09-21 at 19:44, John Hunter wrote:

3

John Hunter wrote:

"Steve" == Steve Chaplin <stevech1097@...49...> writes:
           
   > My view is that a software package should not distribute
   > and install its own dependencies. I think matplotlib
   > should have a list of dependencies (Python 2.2+, Numeric or
   > numarray, ...) which it requires before it attempts an
   > install, and a list of optional dependencies (pytz,
   > dateutil, ...) which matplotlib supports if it finds they
   > 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.

I agree with JDH on this one. Including extra pure-Python packages is not likely to cause (m)any problems:

1) on systems where people do lots of "python setup.py install" the definitive list of installed packages is the contents of site-packages
2) on systems with real package managers (e.g. Debian), this is for the package maintainer to worry about. those extra packages should be made package-level dependencies and not in the matplotlib.deb itself. (this assumes people on these systems are using the package manager. if not, see point #1)
3) on Windows, you want to double click something that just works.

(In fact, by this reasoning, there's nothing against including mixed C/Python packages, either.)