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.
Hi Steve,
Those are reasonable arguments. I'm still convinced that it is better
to err on the side of simplifying the install, though. matplotlib has
been distributing some of it's prereqs for some time (agg, pyparsing)
and not others (Numeric/numarray, freetype, libpng). I try to balance
the likelihood the user already has the package on their system, the
additional ease/complexity of installation and coding, and package
size. On balance, I decided to add pytz and dateutil to the
matplotlib src distro - I won't however, overwrite existing installs.
In the past we've included things (fontutils, ttfquery) that were
eventually removed because we found or wrote better replacements. So
the matplotlib package size tends to fluctuate up and down a bit.
Currently, with src, fonts, icons, examples, example data, and add-on
packages, the src dist comes to 1.6M. I can live with that.
> 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.
I'm amenable. Do you know of instances where people aren't using
matplotlib due to it's version number or development status flag?
My working plan is to be mostly 2D feature complete for 1.0, but I am
not wed to this. As you say, 1.0 really just implies some stability
rather than feature set.
The only thing off the top of my head that must be added before 1.0 is
a Users Guide - I should be done with this already, but alas...
Should be done in a month (I said that last month) I also think it
would also be nice to have a more streamlined, sophisticated configure
process.
The other core features that would be nice to have but aren't
absolutely critical are polar and contour. I believe the stsci folks
are working on contour.
As for stability, there will probably be a significant refactoring of
the renderer drawing API at some point. But I don't think this
precludes a 1.0 release. As long as the matlab interface and OO
Figure/Axes/Text/Line/Patch interface is stable, and it largely is
discussed on the user's list), then I don't think it would break any
existing code to refactor the drawing model down the road. As far as
I know, noone is directly using the renderer API, and I've never
advertised it.
JDH