[SciPy-user] OS-X Universal binary?

[David Cournapeau]

Sebastian Haase wrote:
> On Wed, Mar 25, 2009 at 8:59 PM, David Cournapeau <cournape at gmail.com> wrote:
>   
>> On Thu, Mar 26, 2009 at 4:27 AM, Christopher Barker
>> <Chris.Barker at 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,

cheers,

David