[Numpy-discussion] 1.4.0 installer fails on OSX 10.6.2
Tue Jan 5 17:21:24 CST 2010
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
>> different versions with each OS-X version. If we support the
>> 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
>> provided an up-to-date python that isn't broken. But it's not really
>> 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
>> 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
>> some *.pth trickery into both of the pythons: /System/... and /
>> 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
>> 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...
More information about the NumPy-Discussion