[Numpy-discussion] Re: [SciPy-user] Re: [SciPy-dev] Future directions for SciPy in light of meeting at Berkeley

Bob Ippolito bob at redivi.com
Wed Mar 9 16:52:07 EST 2005

On Mar 9, 2005, at 12:33 PM, Stephen Walton wrote:

>> 2) Installation problems -- I'm not completely clear on what the 
>> "installation problems" really are.
> scipy and matplotlib are both very easy to install.  Using ATLAS is 
> the biggest pain, as Travis says, and one can do without it.  Now that 
> a simple 'scipy setup.py bdist_rpm' seems to work reliably, I for one 
> am happy.

On Mac OS X, using ATLAS should be pretty trivial because the OS 
already ships with an optimized implementation!  The patch I created 
for Numeric was very short, and I'm pretty sure it's on the trunk 
(though last I packaged it, I had to make a trivial fix or two, which I 
reported on sourceforge).  I haven't delved into SciPy's source in a 
really long time, so I'm not sure where changes would need to be made, 
but I think someone else should be fine to look at Numeric's setup.py 
and do what needs to be done to SciPy.

FYI, matplotlib, the optimized Numeric, and several other Mac OS X 
packages are available in binary form here:

> I think splitting scipy up into multiple subpackages isn't such a good 
> idea.  Perhaps I'm in the minority, but I find CPAN counter-intuitive, 
> hard to use, and hard to keep track of in an RPM-based environment.  
> Any large package is going to include a lot of stuff most people don't 
> need, but like a NY Times ad used to say, "You might not read it all, 
> but isn't it nice to know it's all there?"

I also think that a monolithic package is a pretty good idea until it 
begins to cause problems with the release cycle.  Twisted had this 
problem at 1.3, and went through a major refactoring between then and 
2.0 (which is almost out the door).  Though Twisted 2.0 is technically 
many different packages, they still plan on maintaining a "sumo" 
package that includes all of the Twisted components, plus 
zope.interface (the only required dependency).  There are still several 
optional dependencies not included, though (such as PyCrypto).

SciPy could go this route, and simply market the "sumo" package to 
anyone who doesn't already know what they're doing.  An experienced 
SciPy user may want to upgrade one particular component of SciPy as 
early as possible, but leave the rest be, for example.


More information about the NumPy-Discussion mailing list