NOTE: cc-d to the pythonmac list from the numpy list -- this is really a
Mac issue. It's a discussion of what/how to produce binaries of numpy
for OS-X
David Cournapeau wrote:
On Wed, Jan 6, 2010 at 9:18 AM, Christopher Barker
<chris.bar...@noaa.gov> wrote:
If distutils/setuptools could identify the python version properly, then
binary eggs and easy-install could be a solution -- but that's a mess,
too.
It would not solve the problem, really. Two same versions of python
does not imply compatible python when C extensions are involved. In
current state of affairs, where python does not have a stable ABI, the
only workable solution is to target one specific python
So you are saying that binary eggs are simply impossible altogether.
Maybe true, I suppose, but...
As the 2.6 series is binary compatible, you can build a single
installer
that will work with both
I don't think that's true. 2.6.x are compatible with each other iif
they are built with the same compiler options. There are too many
differences between Apple python and the python.org python (dtrace, 64
bits support, compiler options, etc...) IMHO to make a compatible
installer for both versions worthwhile.
Well, it was possible once, and it's been working just fine for wxPython
for a good while. Things may have changed with OS-X 10.6, tough I think
the wxPython binary still works (32 bit only, of course).
I agree that the lack of 64 bits installer is an issue, but building
numpy on mac os x is not that difficult, and I think people who need
64 bits often are more knowledgeable.
I agree -- but what do you get if you install OS-X 10.6, and then type
"python" at the prompt -- is that a 32 bit or 64 bit python?
> There are also solutions like
EPD and the likes, which support 64 bits.
but not PPC anymore, sigh.
There is a key problem here -- folks running OS-X expecting it to be
another Unix are fine -- they install the compiler, build their own
extensions, probably use some combination of fink and macports, etc.
This may well apply to many Scientific programmers, and web developers
(though it maybe not).
However, there is a different type of Mac user -- the type that has
traditionally used Macs. Some of these folks are giving a bit of
programming a try, and have heard that python is an easy to learn
language -- and, cool, OS-X even comes with it installed!
But then they soon enough discover that they need additional packages of
some sort --- and numpy is a very, very useful package, and not just for
the experienced programmer (think Matlab users, for instance). These
folks haven't installed the compiler, don't know 64 from 32 bit, and
heaven forbid, have no idea how the heck to compile a dependency with
the "./configure && make && make install" dance.
Some years ago, the community on the pythonmac list made significant
efforts to try to support these folks. Primarily what they need are
binary installers. We also more or less declared the python.org python
as the official python to support, and even had a repository of
pre-built packages (http://pythonmac.org/packages/py25-fat/index.html).
It was pretty handy -- you could get python itself and all the major
packages there, all working together.
That repository is not longer maintained, for a couple reasons:
1) Bob Ippolito is doing other things
2) A lot of package developers are providing binaries themselves
3) It's gotten even messier!
But there is still a community out there that it would be nice to support.
So the question is: how do we do it? That repository appears to be dead,
though it could be revived if there is a bit of interest. But even
without it, it would be great if there was some sort of consensus among
the pythonmac crowd and the major package developers as to what to
provide binaries for. We're really in a mess if you can only get a
binary for PIL for the Apple Python, and only get a binary for numpy for
the python.org python.
Personally, I still think the Apple python is dead-end -- Apple has
never supported it properly. And, if you go that route you need a
different build for people running 10.4 and 10.5, and 10.6, and ...
I'm not sure what the 64 bit story is -- I suspect that David is right
-- folks running 64 bits are the ones that know what they are doing, so
they have less need for binaries. So maybe for now this is a good goal:
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!
NOTE: Ned Deily just posted a good summary of what's out there on teh
pythonmac list:
http://mail.python.org/pipermail/pythonmac-sig/2010-January/022031.html
-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
