[SciPy-user] OS-X Universal binary?

David Cournapeau david@ar.media.kyoto-u.ac...
Thu Mar 26 01:07:36 CDT 2009

Sebastian Haase wrote:
> On Wed, Mar 25, 2009 at 8:59 PM, David Cournapeau <cournape@gmail.com> wrote:
>> On Thu, Mar 26, 2009 at 4:27 AM, Christopher Barker
>> <Chris.Barker@noaa.gov> wrote:
>>> David Cournapeau wrote:
>>>> I created a new ticket:
>>>> http://projects.scipy.org/numpy/ticket/1067
>>> Thanks.
>>> This brings up a n issue from way back -- with the trickiness of Fortran
>>> support, it would be nice if one could use the parts of Scipy that don't
>>> need it.
>> That sounds like a good idea, until packages using scipy will break on
>> your fortran-disabled scipy. We should avoid variations of the scipy
>> capabilities as much as possible.
> This of course reminds of a fundamental discussion from long ago -- as
> I remember there were plans to split scipy into sub-packages that
> would possibly be able to live by themselves and make the whole thing
> easier to install.
> "there was a time when numpy was called scipy-core ..."
> Anyway, even if this plan is not to be followed through, I would like to know:
> * What are "easily separable packages" ? I would think ndimages might
> be an examples, or ?

Almost every package in scipy/ can be installed separately. I actually
do that quite often when porting on 'exotic' platforms like win64 or
solaris: I only first try to build/install/test the pure C code,
removing any package which depends on fortran. This works really well
from a build POV.

But I don't think it is desirable to enable such scipy installation for
the end users, not in the current state of things (if we could have
something like cran for numpy, I would certainly change my mind). Being
able to install things which don't depend on C++/Fortran would mean that
the fortran parts are even less tested. And fundamentally, I don't think
scipy wo fortran would be that useful: no fft, no linalg, no special
functions. Who can use this ?

Being able to strip things inside a package (inside scipy/interpolate
for example) is a very bad idea IMHO, because different scipy
installation would have different configurations. If you have a package
which depends on scipy, you would have to test whether scipy.special
support the function you request.

> * Would numscons make such a separation potentially more feasible than
> it used to be ?

I don't think so, unless I misunderstand what you mean by separation,



More information about the SciPy-user mailing list