[Numpy-discussion] Numeric3

[Fernando Perez]

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:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138683

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

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 
the following:

/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 
CVS.

Just my $.02

Cheers,

f