[Numpy-discussion] 1.4.0 installer fails on OSX 10.6.2

[Pierre GM]

On Jan 5, 2010, at 6:22 PM, David Warde-Farley wrote:
> 
> 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

OK, so there's still no 64b Python on python.org ? Gonna stick with Apple's then (I remember using a lot of sleep hours when I upgraded to 10.6...)


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


+1 w/ David as well.
Christopher, thanks a lot for the info. I'm glad I don't have to deal w/ packaging issues...