[Python-Dev] Any NeXT users out there?

[Jack Jansen]

> Do you really need to call the option --with-next-framework? First, I
> think it should be an --enable option, since you are not offering to
> use or not to use some external tool or library.

I'm unsure, I've never fully understood the intention behind --with and 
--enable. For instance, why is it "--enable-unicode" and "--with-threads"?

I agree that the "next" bit should probably go, leaving "--with-framework" or 
"--enable-framework".

> Furthermore, I find
> it very confusing to have to invoke incantations involving NeXT when
> compiling software for Mac OS. That Steve Jobs is head of the company
> is *not* enough reason :-)

The alternative is of course that we also provide a 
"--with-previous-framework". Any suggestions as to what it should do? :-)

> Out of curiosity: Just what is a framework? (Should that be Jack, what
> is a framework ?-)

On a low level a framework is really little more than a directory containing a 
collection of directories and symlinks, with a bit of support in the 
compiler/linker (-framework option) and the dynamic loader (searching for 
frameworks over a search path).

On a high level it is a very nifty way to package a shared library complete 
with all its supporting files. These supporting files range from things used 
at runtime (like the python Lib directory) to the C header files needed when 
you want to link against the library to the documentation. Everything is in a 
single directory, so install/uninstall is a breeze with no danger of missing 
things. Also, the structure of a framework allows you to have older, 
incompatible versions of the library (and support documents) in the framework 
as well, with these older versions only used by programs that were linked 
against the framework when that version was current.

A framework is really an instance of a bundle. The other type of bundle is an 
Application Bundle, which is (you guessed it) a directory containing an 
application binary together with all of its support files. A very nifty 
feature is that you can put the frameworks that an application uses into the 
application bundle, thereby forestalling problems like Windows dll-hell. The 
application will even pick up newer, compatible, versions of the framework 
from the system directories if they happen to be there.

The framework patch in sourceforge is the first step. The next step is to 
create a Python application bundle. We can then use a single trick in the 
Python main() program, where it will check to see whether it's being run from 
an application bundle and, if so, whether there's a magic file in the bundle 
(__main__.py comes to mind). If there is Python will run that file as the 
script. This will give Python users "freeze" functionality without using a 
compiler. (MacPython users have enjoyed this functionality for quite some time 
already, with BuildApplet and BuildApplication).

And, of course, if we take the Python application bundle with the __main__.py 
in it and stuff the Python framework into its Frameworks subdirectory we have 
a complete standalone application that can be drag-drop installed without 
having to touch a C compiler, without having to install Python, and which 
won't even interfere if you happen to have an incompatible version of Python 
installed already. And you can uninstall it by dragging it to the trash 
without fear that you will wreck your existing Python installation in the 
process!

Once all this is in place (1-2 weeks, I think) I would really like to try it 
with a Real World application. Zope is the first one that comes to mind, but 
there may be other options. I'd like to hear if someone wants to put some work 
into this.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm