[Pythonmac-SIG] Let's do it completely different!

[Jack Jansen]

Hello folks,
after arguing myself blue in the face for the last year and finally 
convincing the majority here that Frameworks Are A Good Thing I feel 
the time has come to reverse my position. Or, at least, I'm not as 
convinced as I was. And I think I can see advantages with going 
non-framework. Or at least keeping both options open. I don't know, 
just read on and comment, please.

The framework option has the following advantages:
1. Easy installation and de-installation, everything lives in 
/Library/Frameworks/Python.framework or /Applications/Python.
2. Allows us to do applets (such as the IDE) without duplicating big 
binaries.
3. Allows us to do "pythonw" and "PythonLauncher": running Python 
scripts with a GUI that appear normally in the dock, etc.
4. Allows us to share a single Python engine between Python and all 
embedders of Python (such as the Python OSA component).

I think we can do an architecture without frameworks that will allow us 
to do all of these except 4.

To start we build on the existing Apple-installed /usr/bin/python (or 
any other pre-installed Python, from fink or whereever). So, our 
MacPython-OSX installer does not necessarily include Python itself. 
This gives two immediate advantages: we can stuff everything into 
/Applications/Python (making installation and de-installation even 
easier) and we can do a MacPython-OSX distribution without waiting for 
Python 2.3. This would give people like Walt a decent way to explore 
Python through the IDE, without having to learn about the unix command 
line.

Applets we do with a two-stage approach. First, each applet will have a 
symlink Contents/MacOS/python pointing to /usr/bin/python. Second, the 
main binary of the applet .app bundle (CFBundleExecutable) will be 
Contents/MacOS/runapplet. This is a small program that finds the applet 
file and calls ..../Contents/MacOS/Python with the applet code as 
argv[1]. The rest of appletrunners args are also passed through. This 
is the bit that needs to be tested, but I think that if we do things 
this way the final executable will have an argv[0] that points into the 
.app bundle, and thereby the window services initialization code will 
work.

"pythonw" is now easy: we can just use the Contents/MacOS/python from 
any applet. We could use the PythonIDE, but as that would give every 
running Python GUI script the IDE icon in the dock it may be nicer to 
put an empty applet PythonW.app into 
/Applications/Python/PythonIDE.app/Contents/Resources.

PythonLauncher basically doesn't change.

A last issue is where we put our nifty Mac modules (that are now in 
Mac/Lib inside the framework, plus _waste.so and anything else that we 
need and that's missing from the 2.2 that Apple distributes). One 
option would be to install them into 
/usr/lib/python2.2/Lib/site-packages. A possibly nicer option would be 
to also put them somewhere in Contents/Resources of the IDE, and put a 
MacPython.pth file into site-packages.

Fire away folks,
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -