[Numpy-discussion] 1.4.0 installer fails on OSX 10.6.2

David Warde-Farley dwf at cs.toronto.edu
Tue Jan 5 18:22:23 EST 2010

On 5-Jan-10, at 6:01 PM, Christopher Barker wrote:

> The python.org python is the best one to support -- Apple has never
> upgraded a python, has often shipped a broken version, and has  
> provided
> different versions with each OS-X version. If we support the  
> python.org
> python for OS-X 10.4, it can work for everyone with 10.4 - 10.6.
> It's changing a bit with OS-X 10.6 -- for the first time, Apple at  
> least
> provided an up-to-date python that isn't broken. But it's not really  
> up
> to date anymore, anyway (2.6.1 when 2.6.4 is out. I know I've been
> bitten by at least one bug that was fixed between 2.6.1 and 2.6.3).

AFAIK, the System Python in 10.6 is 64-bit capable (but not in the  
same way as Ron Oussoren's 4-way universal build script does it).  
Pretty sure the python.org binaries are 32-bit only. I still think  
it's sensible to prefer the

> As the 2.6 series is binary compatible, you can build a single  
> installer
> that will work with both -- Robin Dunn has done this for wxPython. The
> way he's done it is to put wxPython itself into /usr/local, and then  
> put
> some *.pth trickery into both of the pythons: /System/... and / 
> Library/...
> It works fine, and I've suggested it on this list before, but I guess
> folks think it's too much of a hack -- or just no one has taken the  
> time
> to do it.

+1 on the general approach though it might get a bit more complicated  
if the two Pythons support different sets of architectures (e.g. i386  
and x86_64 in System Python 10.6, i386 and ppc in Python.org Python,  
or some home-rolled weirdness). With wxPython this doesn't so much  
matter since wxMac depends on Carbon anyway (I think it still does, at  
least, unless the Cocoa port's suddenly sped up an incredible amount),  
which is a 64-bit no-no.

I'm not really a fan of packages polluting /usr/local, I'd rather the  
tree appear /opt/packagename or /usr/local/packagename instead, for  
ease of removal, but the general approach of "stash somewhere and put  
a .pth in both site-packages" seems fine to me.


More information about the NumPy-Discussion mailing list