Joe Harrington wrote:
> Someone questioned why to put Ipython into scipy when it's easy for
> Linux users to install scipy and ipython separately. However, that's
> true of several of our packages. There are two reasons to include
> ipython:
>> 1. The sense of the BoF was that the user docs should *only* describe
> using Ipython, with the exception of a brief section describing how
> to start and use plain Python. It won't be discussed as an
> optional thing, and the docs will make heavy use of its
> capabilities. We want to reduce the possibility of problems, and
> since Ipython is not large or on a rapid development schedule, it
> makes sense to include it.
As far as I can see, these decisions can be supported entirely by
packaging and advertisement. Wedging IPython into the scipy source tree
doesn't, to my eye, have any tangible benefits above that. Since IPython
should always be available without scipy (I claim), we're always going
to have two packages.
> 2. As Eric has stated in the past, scipy is supposed to be an
> inclusive package, providing everything you need or would
> reasonably want. There are certainly other packaging philosophies,
> but that's the one he's chosen for scipy.
I think that statement is more true of Enthon than it is of scipy, the
package, at least in the broad interpretation you are putting on it. I
see scipy as being an inclusive *library* for doing scientific/numerical
work. IPython is not, in its current form, a good library. It will be; I
have that much faith in Fernando's abilities. It may make sense to
revisit this question then.
> This makes a lot of
> sense for Windows and other places where installing is a drag.
> There are some exceptions, of course, such as things on a rapid
> release schedule (like matplotlib) and specialized application
> software, particularly the big stuff. Excluding these is more of a
> practical decision than a principled one.
I think scipy should be a good library for scientific work. I think
IPython should be a good interactive environment and eventually a good
library for building interactive environments.
One can make a good interactive environment for doing scientific work by
using IPython and scipy together. One day, Envisage, Ipython, and scipy
are all going to work together and then one will be able to make a good
interactive GUI environment for scientific work.
But none of this requires that they all be part of the same package
("package" as in "from scipy import linalg"). Enthon and other such
packages ("packages" as in "apt-get install enthon") fill this role much
better. They can also include all the pieces like pytables, ctypes,
wxPython, Kiva, Chaco, Traits, Enable and the like that we *really*
don't need to put under scipy.
--
Robert Kern
rkern at ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter