[Pythonmac-SIG] Lion

[Ned Deily]

In article <rowen-B7BD6D.12105422072011 at news.gmane.org>,
 "Russell E. Owen" <rowen at uw.edu> wrote:

> In article <BD2A3E7E-AAAD-42B9-A310-0B981498F61E at mac.com>,
>  Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> 
> > On 22 Jul, 2011, at 6:10, Aahz wrote:
> > 
> > > On Thu, Jul 21, 2011, Ned Deily wrote:
> > >> 
> > >> Although it's not practical to build packages with C extension modules 
> > >> on 10.7 for the traditional 32-bit-only python.org Pythons (as explained 
> > >> above), it is possible to build such packages with the same Python 
> > >> installed on a 10.6, 10.5, or even 10.4 system, create a Distutils bdist 
> > >> or setuptools/Distribute bdist-egg and then install the binary 
> > >> distribution on the 10.7 system.  I would avoid going down that path if 
> > >> possible, unless it is needed as a temporary transition phase.
> > > 
> > > Why?  Isn't that the only way to get a multi-platform build?
> > 
> > It is the only way to get a build that works with PPC systems, with some 
> > care
> > you can binaries on 10.7 that work just fine earlier releases.
> > 
> > To create binaries that work on 10.5 (or even 10.4) you'll need a new
> > python install though, the Intel-only installer on python.org only supports
> > 10.6 or later due to the Tkinter dependency.
> > 
> > The hardest  part w.r.t. binaries that run on earlier versions is that C 
> > software
> > that uses a configure script might detect features on your build system
> > that aren't available on earlier releases.
> > 
> > Ronald
> 
> Rob Manegan suggested another approach that I am considering: install 
> the older SDKs on XCode 4.1.
> 
> I found a link that provides clear instructions:
> <http://hints.macworld.com/article.php?story=20110318050811544>
> 
> Personally I'm happy to ditch PPC and MacOS X 10.4, but I'm not in a 
> position to abandon MacOS X 10.5 users yet. However, from what you said 
> it sounds as if the only way to build extensions with the 32-bit 
> python.org python is to install the 10.4/ppc support.
> 
> So I think my options (since I need to distribute an app that can run on 
> 10.5 and later) are:
> - Install 10.4 support in XCode 4.1, as above. The main annoyance with 
> this is the need to stay at gcc 4.0.

Note those instructions were for installing both Xcodes on 10.6, not 
10.7, and before Xcode 4.1 was released.  So be cautious.  But it should 
be possible to make it work on 10.7.  But, of course, it's not something 
to recommend for the casual user.

Also, IIRC, the big main reason we stayed with gcc-4.0 and the 10.4u SDK 
was that the 10.5 SDK did not support the PPC G3 machines (like the 
Pismo) which are supported by 10.4 (but not 10.5).  If you don't need to 
support them, you may be able to get by with the 10.5 SDK.

As it stands, the current 32-bit-only python.org installers will work on 
any Apple machine that was supported to run 10.3.9 through 10.7 
(excluding the issue of extension building on 10.7 and probably 10.3 as 
well). 

> - Build extensions on 10.6 or earlier. This is not a big deal because 
> keep an old laptop around for this purpose due to unresolved backward 
> compatibility issues building matplotlib and PIL binaries on 10.6.

This is probably the safest option.

> - Switch to ActiveState Python (since they offer a 10.5-and-later python 
> and python.org sadly does not) or build my own. This involves a bit of 
> licensing headache as I have to renew a free license every year.

Again, as long as you don't mind ditching 10.5 PPC users as the A/S 
Python distribution is Intel only, I believe.

We discussed having a python.org 10.5+ 64-bit/32-bit installer; in fact, 
there was a 3-way universal for the original 2.7 release.  But that was 
before there was a reasonable 64-bit Tk solution which unfortunately 
does not include PPC.  We could look at going back to that for future 
releases but I think it is not a good idea at this point.  There are 
other differences between 10.5 and 10.6 (missing API's, older libraries, 
etc); it would mean either not supporting some of the machines that can 
run 10.5 (PPC); and 10.6 is a much cleaner dividing line, IMO.  That is, 
from the perspective of what Python needs from OS X, the gap between 
10.5 and 10.6 is much wider than that between 10.6 and 10.7.   We also 
have some important new options to explore for future releases, like 
moving from gcc to clang, among many other things.  Given our very 
limited development and testing resources, I think the time is better 
spent looking to the future than more work on the past.  For future 
releases (next year's 3.3 for instance), we'll need to look closely at 
just what we claim to support in the form of installers.  Certainly, we 
won't want to break or remove support in the source for existing older 
platforms (10.3.9+) but clearly their importance is fading.

-- 
 Ned Deily,
 nad at acm.org