[SciPy-user] Re: [SciPy-dev] Future directions for SciPy in light
of meeting at Berkeley
bob at redivi.com
Wed Mar 9 18:51:03 CST 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 SciPy-user