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... _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
