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

[Bob Ippolito]

On Dec 23, 2004, at 6:12 PM, Jack Jansen wrote:

> 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

There is the small issue of Zope X3 not being compatible with MacPython  
2.3.0 .. so perhaps a 2.3.5 distro should also be considered, or  
considered instead of the additions?

> 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.

Hopefully the GUI bugs are fixed too?  unless..

> 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?

What about distributing a version of Ronald's written-in-PyObjC  
PackageManager instead, and having MacPython 2.4.1 and MacPython 2.3.5  
coming batteries included with PyObjC 1.2 plus py2app 1.7 (replacing  
BuildApplet with py2applet)?

PyObjC is pretty damn stable software.  I used 1.1 originally but now  
svn trunk from a few weeks ago (to address some potential issues with  
future versions of the objc runtime) in a shipping in-the-apple-store  
Mac application.  I also don't think that between the schedules of  
Ronald, Bill, and myself, that we'll be releasing 1.3 shortly after  
1.2.

If this is done, it should of course be done in the site-packages dir,  
so that it can be reasonably upgraded at some point if py2app  
(definitely) or PyObjC (maybe) is updated between January and the next  
MacPython release.

> 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.

Added bonus is that the extensions will be cross-compatible with any of  
the Python runtime of the same API version (system, user-built, fink,  
dp, etc.).

> 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?

+1 for the administrator privileged in-place patch to 10.3.x's 2.3.0  
(can/should be just an installer .pkg), the runtime hack is gross and  
this is a very controlled environment so I say let's just fix it in the  
right place.

+1 for getting 2.4.1 and maybe 2.3.5 to build a usable destroot  
framework for Darwinports.

+0 for any patches to 2.3.x explicitly for Fink or Darwinports.   
Darwinports uses -flat_namespace for 2.3.x, so that would have to be  
fixed too, which I'm sure has repercussions for people who already have  
Python 2.3.x installed and some modules built and also probably for  
other Portfiles.  I don't know/care about Fink.  This can be fixed on  
their own schedules by their own people once the patch is in 2.3.5 (if  
they decide to adopt a framework build).

-bob