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@oobleck.astro.cornell.edu> To: <numpy-discussion@lists.sourceforge.net> Cc: <jh@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion