[Numpy-discussion] 1.4.0 installer fails on OSX 10.6.2

[David Cournapeau]

On Thu, Jan 7, 2010 at 1:22 AM, Christopher Barker
<Chris.Barker at noaa.gov> wrote:
> NOTE: cc-d to the pythonmac list from the numpy list -- this is really a
> Mac issue. It's a discussion of what/how to produce binaries of numpy
> for OS-X
>
>
> David Cournapeau wrote:
>> On Wed, Jan 6, 2010 at 9:18 AM, Christopher Barker
>> <Chris.Barker at noaa.gov> wrote:
>>
>>> If distutils/setuptools could identify the python version properly, then
>>>  binary eggs and easy-install could be a solution -- but that's a mess,
>>> too.
>>
>> It would not solve the problem, really. Two same versions of python
>> does not imply compatible python when C extensions are involved. In
>> current state of affairs, where python does not have a stable ABI, the
>> only workable solution is to target one specific python
>
> So you are saying that binary eggs are simply impossible altogether.

More simply, you can't offer a single binary installer which works on
binary-incompatible python versions.

> I agree -- but what do you get if you install OS-X 10.6, and then type
> "python" at the prompt -- is that a 32 bit or 64 bit python?

64 bits, at least by default. All the userland provided by OS-X is 64
bits AFAIK (the only apps still 32 bits on my macbook are vmware and
the kernel).

There is also the problem that controlling the minimal supported
version of OS X is hard to control (another distutils insanity).

> However, there is a different type of Mac user -- the type that has
> traditionally used Macs. Some of these folks are giving a bit of
> programming a try, and have heard that python is an easy to learn
> language -- and, cool, OS-X even comes with it installed!
>
> But then they soon enough discover that they need additional packages of
> some sort --- and numpy is a very, very useful package, and not just for
> the experienced programmer (think Matlab users, for instance). These
> folks haven't installed the compiler, don't know 64 from 32 bit, and
> heaven forbid, have no idea how the heck to compile a dependency with
> the "./configure && make && make install" dance.

Those people already have numpy installed, though.

The only solution I can see for a one-click install is to control the
whole stack, e.g. like EPD eos.

> Some years ago, the community on the pythonmac list made significant
> efforts to try to support these folks. Primarily what they need are
> binary installers. We also more or less declared the python.org python
> as the official python to support, and even had a repository of
> pre-built packages (http://pythonmac.org/packages/py25-fat/index.html).
> It was pretty handy -- you could get python itself and all the major
> packages there, all working together.

I hope that our own scientific repository will be able to do this - at
least that's one of the stated goal (see the toydist discussion). The
only scalable solution I can see is if the packages are automatically
built for every version of Mac OS X we wish to support.

>
> Personally, I still think the Apple python is dead-end -- Apple has
> never supported it properly. And, if you go that route you need a
> different build for people running 10.4 and 10.5, and 10.6, and ...

I am afraid that this is needed anyway once you start depending on
"high-level" stuff from Mac OS X API.

> Darn, that's quite a few to support!

I would say that's insane :) That's hopeless intractable. If the numpy
stats are any indication, only supporting the last released python
version is enough for most users.

IMHO, it is much better to support only one binary installer which
works well rather than a myriad which work half the time, and only
confuse people anyway.

David