Ned,
Thanks for the detailed review -- what a mess! I've got a longer note
about this at work -- apparently I failed to send it before catching the
bus, but a few clarifications:
2) we're talking on that list about implementing what Robin Dunn has
done for wxPython -- a single installer that puts numpy somewhere, then
puts *.pth files in both the Apple and Python.org Pythons, so that a
single installer will work with both.
Without knowing the details, that could be a dicey proposition if there
are any C extensions involved.
well, c extensions are the whole point -- this is all pretty trivial for
pure-python.
There is no guarantee that a single set
of binaries would work on multiple instances of python, even the same
source level, if the pythons themselves were not built with the same
options and tool chains. At the moment, that certainly is not true for
the Apple and the python.org pythons in any of 10.4, 10.5, and
especially 10.6.
odd -- it's been working for a while for wxPython -- python 2.5 and 2.6
32 bit universal, though I don't know if it works on 10.6. It sounds
like Apple has made it even more ugly now.
In 10.6, Apple supplies a Python 2.6.1 (3-way build with 64-bit Intel as
default)
so if you type "python" on a stock system, you get 64 bit?
and a Python 2.5.4 (2-way 32-bit only) both built with GCC
4.2.1. 2.6.1 has a deployment target of 10.6 while 2.5.4's is 10.5:
so neither of these is any good if you want to use py2app and distribute
to older systems.
Are we going to need multiple installers, maybe 32 and 64 bit?
That will probably result in two separate installers for each
python version: one 32-bit only built as in the past for 10.3.9+ and a
new 2-way (Intel-only 32/64, 10.6 or higher) or 3-way (2-way plus ppc,
10.5 or higher).
OK -- I still think it's a good idea for us, as a community to try to
support a particular small set of binaries with binary packages. In the
past is was "the python.org build"
I still don't think distributing binaries for Apple's builds is a good
idea -- it's just not universal enough. For now, I suspect these are the
best options:
python 2.5:
python.org build (32 bit PPC and intel)
python 2.6:
32 bit python.org 2.6.4
64 bit python.org build?
python 2.7:
python.org 3-way build, if that happens.
or separate 32 and 64 bit builds
python 3.1:
python.org build (whatever it ends up being)
Darn, that's quite a few to support!
If there is a 3 (or 4) way build, will you be able to build and install
a 32bit only package (like wxPython) for it?
From another thread:
Adam Morris <amor...@mistermorris.com> wrote:
As for the debate about binaries, it seems to me that if there was better
explanation of how to use Python effectively on the various operating
systems, it would help a lot. Basically, install 2.6.4 and be done with it.
He's right -- we want to be able to provide a simple message.
Unfortunately, it's not always that cut-and-dried. For instance, the
current python.org installers are currently 32-bit only; the
Apple-supplied Python 2.6 supports 64-bit as well. That's important for
some users.
So at least we can say:
if you don't need 64 bit, install the latest python.org build (either
2.5, 2.6, or 3.1)
If you need 64 bit, I guess you're stuck with Apple's build, though
hopefully there will be another option before too long.
Thanks,
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
