[Numpy-discussion] scipy, matplotlib, and installation dependencies.(previously: Numeric3)

Perry Greenfield perry at stsci.edu
Sat Feb 5 17:49:10 CST 2005


Travis Oliphant wrote:
> >
> But MATLAB is a huge package.  SciPy has been trying to do the same 
> thing.  Plotting was needed and matplotlib did a great thing in 
> providing excellent plotting.  I've never understood the reason for 
> matplotlib to remain separate except as evidence of the great schism 
> that was occuring in the community.
> 
> In fact, when Eric and I began scipy, I wanted to call it pylab (you'll 
> notice I have the pylab.sourceforge.net site).  I have fond ties to 
> MATLAB myself.    Eric chose the scipy name which is probably better.  
> So, it is very concerning to me to see matplotlib try to become what 
> scipy is already trying to become.   I think it is very confusing to 
> newcomers.
> 
I think you are reading far too much into the overlap between
matplotlib and scipy. Yes, matplotlib duplicates some numerical
functionality, but the plotting and image display aspects of 
matplotlib are far and away the primary focus. Comparitively
little of it is devoted to numerical libraries. Likewise, 
although scipy has had plotting capability, we all recognize 
(at least I think we do) that it left a lot to be desired and 
was considered by most a stopgap until a better plotting solution
was found.

So this leads to the question: why wasn't matplotlib developed 
for scipy? You'll have to ask John for a definitive answer, but I 
think I can guess. As you may have noticed, many are fearful of 
building lots of dependencies into their library or package. That's
understandable. The more there are, the greater the chances that
installation will be too painful. Scipy has many such dependencies.
Until it has a reputation of being an easy install, it's unlikely 
lots of packages with a much narrower focus will depend on it.
Hence all the requests for something along the scale of what Numeric
packages rather than just all of scipy.

There are two competing forces at work here. One is to bundle
everything together and do the work of making sure it all plays
together nicely thus avoiding the pain of installing N different
packages independently (what scipy is trying to do). That's great
as far as it works easily, but with so many dependencies, more 
risk there is of one of them causing unsophiscated users (and 
even the sophisticated) stumbling on installation. The other 
force is for minimal dependencies. It makes for less headaches
for the package maintainer, but for users that have to install
several components, it can be more of a hassle.

Can scipy be made to be a painless install for most users? I'm 
not sure we know the answer yet. Until we do, I'd favor an approach
that shoots for a smaller, easily installable core, with a simple
way of asking for optional packages (having users edit setup.py
is probably asking too much). When packages prove that they are
reliably installed under all circumstances, then they can be added
to the core distribution, otherwise, it is understood that the 
optional packages may be tricker to install. The fewer you need,
the better. It seems to me that is what many would like to see,
but maybe I'm misrepresenting the most common point of view.

Perry



> >We've put a fair amount of work in making Numeric and numarray work
> >transparently in matplotlib at the python and extension code level.
> >Having a third array package in the wild which is incompatible with
> >either is an unattractive option for me, but one which I can deal with
> >if need be.  And if the goal is to get an array package into the
> >standard library that has the core functionality of Numeric and
> >numarray, and Numeric3 is the most sensible means to that end, then I
> >am all for it.
> >  
> >
> Again,  from my perspective once Numeric3 is working reasonably well, 
> Numeric ceases to exist for me.  Yes others may continue to download it, 
> but I won't be maintaining it anymore.
> 
> -Travis
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 





More information about the Numpy-discussion mailing list