[Pythonmac-SIG] Framework considered harmful

[Jack Jansen]

Recently, bill fancher <bfancher@mac.com> said:
> I discussed this privately with Tony Lownds a while ago, and expressed the 
> opinion that building as a framework is a bad idea. I should have gone 
> public earlier.
> 
> I believe Python on Mac OS X should look as much like Python on any other 
> platform as possible. Leave the "special" stuff for Windows and other 
> non-POSIX systems.

I'd like to discuss this topic a bit more (anyone with an opinion:
please chime in now, this discussion could shape the future:-).

First off, let me note that building a framework is optional, and
should remain so. There are lots of people who will want Python only
for commandline use or CGI scripting or whatever, and a
framework-based Python will not have any substantial benefits to them.

Second, as the next distribution is going to be an alfa we should
start using both the framework and the non-framework version. If it
turns out the framework is a bad idea we should drop it. If it turns
out it needs to be done differently we should do that.

Third, I like to view MacOSX as a new version of MacOS, that happens
to have Unix under the hood to make things work more smoothly. (Before
I get accused of parochialism: I'm the treasurer of the NLUUG, the
dutch sister of Usenix, and I've been using unix happily for the last
24 years!)

Viewing OSX as basically a Mac leads to a number of observations (fire
away!):
- Most users will not want to know about the shell. They will most
definitely not want to know about the developer tool CD.
- This is probably also true for a large number of Python users. The
number of people on this list who have CodeWarrior can be counted on
the fingers of 1 or 2 hands. In the time when the standard Mac
developer tools were free (MPW) this was also true, so cost is not the
only factor.
- Mac users expect smooth and troublefree installation and
de-installation.
- Mac users expect double-click, drag and drop and all that jazz.

These observations lead me to think that the standard Python install
for MacOSX should be binary and as self-contained as possible, like
MacPython is today. An added case for the framework solution is that I
see no clear way to get MacPython-style applet support to MacOSX, at
least not easily. Applets are essential in a drag and drop world, in
my opinion, because it's the only reasonable way to get file arguments
to your script.

An option that I'd like to explore is to put the framework into the
SharedFrameworks of the (to be implemented) Python.app. This might
give the advantages without the disadvantages. But Apple's Inside
MacOSX has a quick paragraph on shared frameworks where they mumble
about a system-wide registry and automatic version tracking and
sharing and then quickly moves on to a more safe subject without
providing any of the details. Does anyone know more details?

> This would be in keeping with guidelines from Apple, which recommend 
> compiling legacy code as is. Neither TCL nor PERL is a framework.

I'm not sure about how Perl is used mainly on the Mac, but I know that
Tcl/Tk is in a very sorry state. As far as I know people basically use
it to run scripts that were ported over from unix under wish. No
toolbox interfaces (a minimal quicktime and applescript one aside), no
other mac integration, etc. They have droplets, but they require
ResEdit to create last time I looked. You wouldn't stand a chance
trying to develop something like GRiNS or Zope in Tcl on the mac.

> There's 
> a reason for this.
> 
> A non-standard configuration is just asking for trouble with third party 
> code and should be avoided if at all possible.

But don't forget that the framework is not a non-standard
configuration! It is a perfectly normal Python installation only it
happens to live in a very far away place. What is installed at the
bottom of the framework jungle is 100% run of the mill, and distutils
has absolutely no problems with it (expect for a bug, which I'll
address in another mail).

> For example, I have code that includes Python headers. Using the framework,
>   I need to change all my code from e.g.
> 
> #include <Python.h>
> 
> to
> 
> #include <Python/Python.h>

Hmm. On the one hand I could say "No, you don't" because distutils
will take care of adding sys.prefix+'/include/python2.2' to your
search path.

On the other hand people could be tempted (if they have no previous
unix/python background) to use bare Project Builder and they would
indeed start using Python/Python.h paths. Will we be able to steer
people writing extensions to use distutils, that's the question, I
guess... Hmm, we could (evil grin) not put the Headers symlink in the
framework, maybe?

> And then I need to add /Library/Frameworks as a framework search path. 
> Alternatively, I can ignore the framework and change things to use the 
> include path
> 
> /Library/Frameworks/Python.framework/Headers

Again, I don't really think so. Distutils handles this for you, and if
you do it yourself you also have to set an include path, Python can
live anywhere. On my SGI at work it lives happily in
/ufs/jack/src/python/built-and-installed, and if you use the SGI
supplied installer it will live in /usr/freeware. There's nothing
magic about /usr/local, except that it's the default.

I'll skip the rest of the points, because i think I've basically
addressed them (but feel free to bring them up again if you think I
haven't, or if I've missed the point).

> p.s. The "Headers" link in /Library/Frameworks/Python.framework is bad.

Thanks, I'll look at it.
--
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