[Pythonmac-SIG] Python development on OSX

[Christopher Barker]

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.Barker at noaa.gov