[Pythonmac-SIG] Let's discuss MacPython distributions for january
Jack.Jansen at cwi.nl
Fri Dec 24 00:12:57 CET 2004
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
- 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
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,
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
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
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
More information about the Pythonmac-SIG