[SciPy-dev] Re: ASP: Ipython in SciPy

[eric jones]

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 
mentioned.

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.

eric

>Remember that
>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
>installation process.
>
>--jh--
>
>_______________________________________________
>Scipy-dev mailing list
>Scipy-dev at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-dev
>  
>