[Pythonmac-SIG] Let's discuss MacPython distributions for january

[Jack Jansen]

With the next version of Ambulant out the door and a whole week off  
(well, only from work, not from the kid or the wife:-) I'd like to get  
some work done on Python again. And with Python 2.3.5 and probably  
2.4.1 imminent that seems to be good timing.

Part of this email is highly technical, but part is (somewhat) end-user  
oriented, so feel free to comment only on the parts that interest you.

In january I'd like to get two MacPythons out:
- MacPython 2.4.1 (full installer for Panther, time permitting for  
Jaguar too)
- MacPython 2.3 additions, version 3

The main feature of these is that they should coexist peacefully. With  
each other, and with user-built (or fink-installed, or whatever) Python  
2.3.5 or 2.4.1. And MacPython 2.4.1 should coexist peacefully with an  
unmodified Apple Python 2.3 (possibly after making slight modifications  
to that 2.3 installation). More on this below.

The second feature is that they'll finally have the newer version of  
Package Manager (or, actually, the underlying pimp module), which  
allows the maintainer (me:-) to have a single database for all 10.3.X  
releases of MacOSX.

And, of course, there's bug fixes for things like the PythonIDE scripts  
folder bug and such.

First question: what am I missing? Anything that should really go into  
either (or both) of these? Any serious bugs that you want fixed?

Second question: I think the solution to peaceful  coexistence is that  
all Pythons adopt the solution sketched in Bob's mail  
<http://mail.python.org/pipermail/pythonmac-sig/2004-December/ 
012292.html>. That discussion is rather technical, but what it boils  
down to is that all Pythons (on 10.3) build their extensions with  
"-undefined dynamic_lookup", thereby forestalling that extensions  
inadvertently pull in a second, different, Python framework.

Fixing this for 2.4.1 and 2.3.5 themselves is rather easy (and sketched  
in the mail mentioned above). Fixing this in the Apple-installed 2.3 is  
a bit more difficult, though. We can either modify it in-place (with  
admin permission) or do a complicated patch that Ronald came up with  
last year. While in general you should not muck with Apple-installed  
things I think that for this once I have a preference for the simple  
in-place modification over the slightly convoluted patch. Opinions,  
anyone?

Then there's the question of how to get the patch in place, and here I  
need a bit of help. For people building Python 2.4.1 from source I can  
add a test (in "make frameworkinstall") for an unpatched Apple 2.3 and  
print a warning that people need to apply the patch. The MacPython  
2.4.1 and 2.3-additions-version-3 installers could simply apply the  
patch. But I'm not sure what to do about Pythons installed by Fink and  
darwinports and other such packages.

There's also the question of the form of the patch. What needs to be  
done (in case of the in-place modification) is a one-line change to  
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
config/Makefile. The patch could either be a shell script (containing a  
simple "ed" command to patch the file, or maybe a Python script so it  
can do some checking) or a .pkg file. The former is easiest for people  
building from source, the latter would also be a partial solution for  
fink users (partial, because it would allow them to apply the patch,  
but there's still no way to warn them that it is needed). Or should we  
do both?
--
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman