[SciPy-dev] Re: ASP: Ipython in SciPy
eric at enthought.com
Tue Nov 2 16:26:05 CST 2004
Joe Harrington wrote:
>Responding to Robert Kern:
>I'm using "package" to mean a single, binary installation file, not a
>python importation object.
>>Since IPython should always be available without scipy (I claim),
>>we're always going to have two packages.
>That's true of almost the entire contents of SciPy.
There is a difference I think. I am a fan of the single integrated
package concept, but mainly in terms of numeric algorithms. There are
many dependencies between packages that make distributing them
individually more difficult. Even with our division of "base" libraries
from the ones that depend on them, we still have some unresolvable
dependencies. For example, the polynomial.py module (part of
scipy_base) depends on linalg if you want to use its roots() function.
Developing SciPy as an integrated set of algorithms makes development
easier in many respects and it provides a full set of tools to the end
user. Both good things. Plotting and IPython don't have the same sort
of dependencies and therefore can easily evolve separately. This makes
the main advantage a ease-of-use for the end user issue. I think we
might solve these things more effectively in other ways as Robert has
My thoughts on plotting have obviously changed because we develop Chaco
(and other tools) outside of SciPy. Coupling them makes less sense from
a development standpoint. Doing it over, we might have chosen to keep
gplt, plt, and xplt outside of SciPy (xplt's setup.py script is
something like 1000 lines...), but it isn't that big of an issue. I
think that rolling Matplotlib or Chaco or IPython or other
semi-orthogonal tools into SciPy is probably not that beneficial right
now. They all evolve at different paces. Also, some have target
audiences that might not want all the other tools.
So, I'd vote for having a download next to SciPy's download on the
website for all of these tools instead of putting them in the same
repository. On the windows platform, we will continue to distribute a
Python Enthought Edition that bundles all of these up into a single
download so the windows people don't have to gather them all together
for a single-click install. For Linux, there is still some effort in
getting all the packages assembled.
>Windows users have a much harder time installing packages than Linux
>people, so fewer packages is much better. Likewise, not all Linuxes
>have YUM or APT. In the long run, I think we'll have our independent
>set of small packages (the core of scipy, Numarray, LAPACK, ATLAS,
>Ipython, Chaco and/or matplotlib, Envisage, scipy-doc, the various
>application packages, etc. etc.) and one or more "umbrella" packages.
>The RPMs and DEBs of the umbrellas may be contentless sets of
>dependencies that cause YUM/APT to get the needed packages, but for
>Windows they may be actual monolithic files with all the content in
>them. Other platforms will follow one or the other model.
>>IPython is not, in its current form, a good library. It will be
>For ASP, I only ever talk about the long term since so much is in flux
>in the short term (graphics, Numarray/numeric, etc.). If Ipython
>needs to be outside of scipy for a while due to a faster release
>schedule, that's fine. Matplotlib is in the same boat. I didn't get
>the impression from Fernando that this was the case, however.
>I think we agree that inside of python it is good to have modularity
>visible. I just want to make it (optionally) invisible in the
>Scipy-dev mailing list
>Scipy-dev at scipy.net
More information about the Scipy-dev