[Numpy-discussion] Meta: too many numerical libraries doing the same thing?

eric eric at enthought.com
Thu Dec 6 19:39:01 CST 2001


Hey Joe,

Your right on many counts.  A single monolithic packages sacrifices the
ability to embed SciPy in other apps.  This is unacceptable as it is one of
the major powers of Python.  On the other hand, a single monolithic (single
download) package is exactly what is needed to introduce the full
capabilities of Python and SciPy to a large number of novice users. I'm
hoping the choice between these two isn't an "either/or" decision.

We've (well Travis O. mostly) been working to divide SciPy into multiple
"levels," and think this provides a solution for a wide range of users.
There are 3 levels now, and there is likely to be a 4th "sumo" level added
later.

Level 1 is the core routines.  Level 2 includes most Numeric algorithms.
Level 3 includes graphics and perhaps a few other things.  The sumo package
would be a large all inclusive package with
Python/Numeric/SciPy/VTK/wxPython(maybe)/PyCrust/MayaVi(maybe) and possibly
others.  Its form hasn't been defined yet, but it is meant to be a
click-install package for the large population of potential users who are
looking for a scientific programming/exploration environment.  The goal of
SciPy from the beginning has been to make Python an appealing platform to
the scientific masses -- not just the computer savvy.  I firmly believe that
somthing like th sumo package is the only way that SciPy will ever take hold
as a widely used tool.  If you require multiple installations, you loose a
huge number of potential users.

The other thing to remember is that there are really two major platforms --
Linux and Windows (and many others hopefully supported).  Linux users are
generally much more savvy and do not mind multiple installs.  But the
windows world remains a huge portion of the target audience, and these
people generally have a very different set of packaging expectations.  If it
ain't click/install/run, they'll simply choose a different package.

We've considered releasing maybe 3 different packages, say level 1/2, level
1/2/3, and sumo so that people can pick the one they wish to use.  On the
good side, this gives the experts the core algorithms packaged up without
much cruft so that they can use it with their current Python and the novice
an easy way to try out all the cool features of Python/SciPy/Visualization.
On the bad side, it introduces maintance headaches and might lead to version
issues.  Still, I'm really hoping a good compromise can be found here.

> If SciPy or any other scientific package includes a Python
> interpreter, it should have a special name, like "scipy", and not be
> "python" to the command line.  Frankly, I prefer the layered approach,
> so long as everyone works to make the layers "just work" together.
> This is quite practical with modern package managers.

I guess the sumo version might have the interpreter renamed scipy -- we'll
wait till at least a few blanks have been laid before we try and cross that
bridge...  On the layering side, I think SciPy is moving in the general
direction that your suggesting.

see ya,
eric


----- Original Message -----
From: "Joe Harrington" <jh at oobleck.astro.cornell.edu>
To: <numpy-discussion at lists.sourceforge.net>
Cc: <jh at oobleck.astro.cornell.edu>
Sent: Thursday, December 06, 2001 6:33 PM
Subject: Re: [Numpy-discussion] Meta: too many numerical libraries doing the
same thing?


> Sorry for the late hit, I have been away at a conference.
>
> Regarding the issue of SciPy including a Python interpreter and being
> a complete distribution, I think this is a *poor* idea.  Most Linux
> distributions include Python for OS use.  I ran into trouble when I
> supported a separate Python for science use.  There was confusion
> (path issues, etc.) about which Python people were getting, why the
> need for a second version, etc.  Then, the science version got out of
> date as I updated my OS and wanted to keep my data analysis version
> stable.  That led to confusion about what features were broken/fixed
> in what version.  If SciPy includes Python, it has to make a
> commitment to release a new, tested version of the whole package just
> as soon as the new Python is available.  That will complicate the
> release schedule, as Python releases won't be in sync with the SciPy
> development cycle.  There is also the issue, if OSs start including
> both mainstream Python and SciPy, of their inherently coming with two
> different versions of Python, and thereby causing headaches for the OS
> distributor.  The likely result is that the distributor would drop
> SciPy.  Further, they will have to to decide which version to install
> in /usr/bin (SciPy will lose that one).
>
> If SciPy or any other scientific package includes a Python
> interpreter, it should have a special name, like "scipy", and not be
> "python" to the command line.  Frankly, I prefer the layered approach,
> so long as everyone works to make the layers "just work" together.
> This is quite practical with modern package managers.
>
> --jh--
>
> _______________________________________________
> 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