Fernando.Perez at colorado.edu
Fri Feb 4 11:39:03 CST 2005
Travis Oliphant wrote:
> O.K. I can see that there are several out there who belive that SciPy
> is sufficiently hard to install that they are concerned about requiring
> it for their math-using packages (despite the provided binary
> distributions, and the work that continues on making it easier to
> install). I'm very glad to hear these comments, as I constantly wonder
> why people seem to be duplicating SciPy's efforts instead of helping
> SciPy. I really would like to help make SciPy into something that many
> people can use. We have done a lot of work in trying to make SciPy
> modular, just for this reason.
I can only speak for a linux (specifically Fedora3) environment. But I'd
venture that much of this fear is based on the old lore of epic battles fought
by many (myself included) against scipy cvs. It is also true that _very
recently_ there have been the many -no-f2c problems, due to the complexities
of handling this flag.
An aside for Fedora3 users, the blas/lapack supplied packages are broken:
Specifically, see my comment 15 there. As of today (2005/02/04), redhat has
completely ignored this. If you want a functional default (non-atlas) lapack,
you must either build it yourself or grab it from rawhide, at least the -28
However, as we've discussed recently on the scipy list, with current CVS, and
my scripts for rpm-building out of Pearu's binary ATLAS/lapack packages,
building a fully installable, sub-architecture-specific RPM for scipy requires
/path/to/scipy-cvs/ > python setup.py bdist_rpm --release=$YOUR_ARCH_TAG
That's it. Period. One single command, and you get a properly tagged RPM
which can be handled automatically on a network of machines with multiple
architectures (you obviously will have to build one for each arch).
What I'm trying to say is that, thanks to all the recent work on this problem,
its MUCH EASIER than most people think, at least under linux.
For Win32, Joe Cooper's Enthon releases basically solve the problem in one
clean swoop, and they include not only scipy, but also a ton of other stuff,
some of which is _a lot_ harder to build than scipy (ever built VTK?).
For OSX, I understand that R. Kern is working on a MacEnthon, which will
hopefully solve the problem in a similar way.
So I fully agree with Travis that it would probably take a lot less work, and
benefit our overall combined goals much more, if people spent a bit of their
time in helping solve the install/distribution issues at the scipy core rather
than reinventing their own side packages. That's been my approach, and Pearu
has been _extremely_ receptive to all my patches and requests, to the point
where now scipy flies in autopilot for me, even keeping it up to date with raw
Just my $.02
More information about the Numpy-discussion