The main reason is because you want to create GUI programs in Python. With

the exception of X11/XDarwin-based GUI toolkits it appears that all GUI programs

While it is technically possible to create a .app without using frameworks

you will have to do the work yourself if you really want this.

A second reason for using frameworks is that they put Python-related items

in only two places: /Library/Framework/Python.framework and /Applications/Python.

if they want to get rid of it again. Moreover, due to the way frameworks

work a user without admin privileges can install a binary distribution in

his or her home directory without recompilation.

get Waste, an all-singing-all-dancing TextEdit replacement, from www.merzwaren.com.

It will unpack into a folder named something like "Waste 2.1 Distribution". Make

a symlink called "waste" to this folder, somewhere beside your Python source

distribution (it can be "../waste", "../../waste", etc).

If you want Tkinter support you need to get the OSX AquaTk distribution. If you

want wxPython you need to get that. If you want Cocoa you need to get pyobjc.

Because all these are currently in a state of flux please refer to

applications (fullblown OSX .app applications, that is) in /Applications/Python,

and a hidden helper application Python.app inside the Python.framework, and

unix tools "python" and "pythonw" into /usr/local/bin. In addition

it has a target "installmacsubtree" that installs the relevant portions of the

Mac subtree into the Python.framework.

This sequence will put the framework in /Library/Framework/Python.framework,

the applications in /Applications/Python and the unix tools in /usr/local/bin.

Building in another place, for instance $HOME/Library/Frameworks if you have no

admin privileges on your machine, has only been tested very lightly. This can be done

by configuring with --enable-framework=$HOME/Library/Frameworks. The other two

directories, /Applications/Python and /usr/local/bin, will then also be deposited

in $HOME. This is sub-optimal for the unix tools, which you would want in $HOME/bin,

but there is no easy way to fix this right now.

Note that there are no references to the actual locations in the code or resource

files, so you are free to move things around afterwards. For example, you could

use --enable-framework=/tmp/newversion/Library/Frameworks and use /tmp/newversion

as the basis for an installer or something.

frameworkinstall is composed of a couple of sub-targets that install the framework

itself, the Mac subtree, the applications and the unix tools.

If you want to run the Makefile here directly, in stead of through the main Makefile,

you will have to pass various variable-assignments. Read the beginning of the Makefile

for details.

window and runs the scripts with the normal command-line Python. For the latter

it runs the script in the Python.app interpreter so the script can do GUI-things.

Keep the "alt" key depressed while dragging or double-clicking a script to set

runtime options. These options can be set once and for all through PythonLauncher's

preferences dialog.

and out comes a full-featured MacOS application. There is much more to this, to

be supplied later. Some useful (but outdated) info can be found in Mac/Demo.

The commandline scripts /usr/local/bin/python and pythonw

can be used to run non-GUI and GUI python scripts from the command line, respectively.

First, to make sure there's no contamination, it is best to remove your existing Python

installation (clear out /Library/Frameworks/Python.framework and /Applications/Python).

Also, after build/install is finished check that nothing has shown up in those two locations.

Create a subdirectory of the main python directory, say build-pythondist. In there, run

../configure --enable-framework=/tmp/pythondist/Library/Frameworks/Python.framework \

This installs a complete distribution set in /tmp/pythondist: in a framework build all other

pathnames are computed from the framework pathname.

Note that the unix tools in /tmp/pythondist are wrong, these have to be removed, and the

installer post-install script should recreate them on the target system. Also, the .pyc and

.pyo files need to be removed:

The PythonLauncher is actually an Objective C Cocoa app built with Project Builder.

It could be a Python program, except for the fact that pyobjc is not a part of

the core distribution, and is not completely finished yet as of this writing.

Something to take note of is that the ".rsrc" files in the distribution are not

actually resource files, they're AppleSingle encoded resource files. The macresource

module and the Mac/OSX/Makefile cater for this, and create ".rsrc.df.rsrc" files

on the fly that are normal datafork-based resource files.

Jack Jansen, [email protected], 12-Aug-02