[Pythonmac-SIG] Extensions for static versus frame

[Chris Barker]

Hi folks,

It seems there is some debate over what the "default" build/distribution
of Python on OS-X should look like. I thought I'd put in my $.02, and
see what others think. In a private message, Jack Jansen wrote:

> I want to have all of Python contained in one spot:
> /Library/Frameworks/Python.framework. Users may install it
> elsewhere, such as in ~/Library/Frameworks/Python.framework or
> so, but it is 100% self-contained, that's the main point.
> (Exceptions to this rule are PythonIDE.app and the soon-to-come
> Python Launcher.app, which will live in /Applications, but that
> is true for both architectures). And it's binary-installable.
 
> Another option is to have a completely normal Unix installation, with files in
> /usr/local/bin and /usr/local/lib/pythonX.Y. This is possible,
> and the Python.framework would then consist mainly of symlinks
> into /usr/local. The bad side of this is that you lose non-admin
> installation, you lose uninstall by simple drag-to-thrash, and
> to people who don't know the Terminal it will be completely
> unclear where this thing lives (/usr is invisible from the
> Finder). The good side is that it is exactly the same filesystem
> layout as on Linux or any other unix.

I am primarily a Linux user, and I don't see much advantage at all to
the second approach. In fact, I really don't like the *nix standard of
sprinkling files realated to a single app all over the system in /usr,
/usr/lib, /usr/share, etc. I much prefer apps that come packaged all up
in a /usr/local/appname directory. The only thing that makes the
standard approach tolerable is if everything is installed by a package
system like rpm. That way it can be upgraded, repaired and uninstalled
cleanly. Apple has not provided such a system, and instead encourages
people to distribute apps in a Framework directory to make maintainance
easier. It's a good idea. What I suggest is a Framework build, with the
following symlinks:

/usr/local/bin/python
/usr/local/bin/python2
/usr/local/bin/python2.2

/usr/local/lib/python2.2

and wherever else we think we need them. This way it will still look
pretty much like a standard install to the Unix side. Note that "real"
unix geeks can do whatever they want anyway, we are only talking about
the "standard" build, which will be installed pre-compiled by most
people. I'm also assuming that distutils will do "the right thing" with
a Framework install.

By the way, I also suggest /usr/local, rather than /usr/, following the
tradition that stuff supplied by folks other than the vendor be put in
/local. That way it is very clear when administering the system what
Apple (or RedHat, or whoever) supplied, and what was hand-installed.

On another issue, but related to what the standard install should look
like:
> If you try to run Python.app twice by
> double-clicking on a second .py script while the first one is still
> running it doesn't work, but I woulnd't expect a bus error (I would
> expect nothing to happen).

This needs to be solved. Except for command line use, Python is not an
application. It is a virtual machine or runtime environment, and should
be invisible to users running multiple python programs at once. Is the
above mentioned "Python Launcher.app" the solution to this?

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov