NOTE:
I'm not trying to persuade Bill of anything -- he's clearly found a
method that works well for him, but for future googlers, I think a few
clarifications are in order:
On 1/18/11 4:29 PM, Bill Janssen wrote:
Bill -- I'm really curious what issues you've had --
In general, there are issues around site-packages, paths, and other such
things. I don't think you and I necessarily have much trouble with it,
but I tend to help others with Python on Macs, and they seem to get into
all kinds of trouble. The best one I've found is one group who had
decided to upgrade their Leopard Python to 2.6. They'd installed the
python.org Python, removed the symlink /usr/bin/python, and re-linked
/usr/bin/python to the 2.6 version. They were happy, but plagued by odd
problems with their machines that didn't (to them) seem to be
Python-related.
OK -- well, I'd say the solution to that is simple: DON'T DO THAT. We
say time and time again that you should NEVER mess with Apple's python.
So there problem was not that they installed another python, but that
they broke Apple's. And there is no need -- they got too smart for their
own good. The python.org installer changes the users PATH anyway.
(granted, not for all users, but if you have a multi user system, you'll
need to know how to manage PATHs anyway -- and /usr/local should be on
everyone's PATH)
Another problem I've run into more than once was that the user had
installed different incompatible versions of an extension, and couldn't
see why an application (with an embedded Python interpreter) was
misbehaving -- it was getting the wrong version of the extension.
Well, Even Apple supplies more than one version these days -- if you are
embedding Python, you're going to need to know what you are doing.
Not sure this is much use to anyone, but here's my decision tree, which
has worked well for me over the past 7 years:
1) Do I do a bunch of unix-y command line stuff in general, and not
want to develop OS-X GUIs?
if yes -- use system Python.
well, I meant a bunch of unix-y stuff in addition to Python -- stuff
that Apple doesn't give you -- I use MacPorts for a bunch of
command-line scientific tools, and it would make some sense to use
macports python for those things, too (dependencies and all).
But yes, if you are doing command line stuff and don't need anything
Apples doesn't give you -- the Apple python is fine (unless you need a
newer version)
if no:
Do I need/want a newer version than Apple provides?
if yes: build non-framework version from source.
I can hardly see this as easier/more reliable than installing the
python.org build -- if you build from source and overwrite
/usr/bin/python, you'll sure get the same problems! And anyone that can
build from source understand PATHs, etc, enough not to screw things up!
Do I need/want to use py2app to distribute my app(s)?
Never happens.
fair enough.
Do I want to use pre-build binaries of common hard-to-build packages?
if yes: cry about the general unfairness of the world, then build them
from source instead to work with the system Python.
Why cry when wxPython, PIL, SciPy, Matplotlib, ??? are available as
nifty easy to use installers?
There really aren't very many people for whom "build it from source" is
the best option.
Final NOTE: It's great that Bill takes this approach -- he's gotten
things working and helped others a lot -- someone's got to build from
source! Thanks, Bill!
-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
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
