[Python-Dev] OS X Installer for 3.0.1 and supported versions

[Ronald Oussoren]

On 14 Feb, 2009, at 12:22, Ned Deily wrote:

> Speaking of an OS X installer for 3.0.1, over the last few weeks I  
> have
> been working on tidying up the OS X installer build process.  While  
> the
> basic OS X build/installer process is good, some cruft has accumulated
> over the past years and a number of mostly minor issues arose due to  
> the
> 3.x split.  IMO, the most important issues were with IDLE and,  
> thanks to
> Ronald, we did get the most important fixes for OS X IDLE checked-in  
> in
> time for 3.0.1; they are also in py3k and will be going into trunk and
> 26.  I have a few other fixes that apply just to the OSX build/ 
> installer
> parts which did not get submitted in time for the 3.0.1 cutoff but  
> which
> are ready to go for 3.x and 2.x.  Basically they fix some version  
> number
> updating and ensure that the installer image will be built  
> reproducibly
> in a clean environment so there is no contamination of the installer
> images.  Currently, that's easy to do as happened with the first round
> of the OS X 2.6 installer (e.g. with a locally installed Tcl/Tk).   
> They
> also allow images to build for various OS X version.  More on that  
> below.

There's one problem with building with an entirely clean environment  
though, the 2.5 installers were build with a locally instaled Tcl/Tk  
on purpose. Such a build uses a locally installed Tcl/Tk when  
available and uses the system version when it is not. Several Tkinter  
users on OSX pushed heavily for that because appearently the system Tk  
is much less usable than the 3th-party install.

I don't care much either way, IMHO the look and feel of Tk apps sucks  
with either version of Tcl/Tk and I don't use Tkinter anyway.

>
> I would like to get to the point where the OS X images can be  
> generated
> and tested automatically.  I think that is reasonable and achievable.
> It's not quite there yet but I can now semi-automatically produce  
> images
> for 2.6, 2.7 (trunk), 3.0, and 3.1 (py3k) in both the traditional  
> "fat"
> (32-bit i386) for 10.4/10.5 and, for 10.5, "universal" (4-way 32-bit  
> and
> 64-bit intel/ppc).  They all have been passing the standard regrtest
> with no new obvious (to me) regressions but I certainly won't claim to
> have done complete and thorough testing.  (In particular, I have no
> access to a G5 for 64-bit PPC testing.)

I'd love to get to the point where it's possible to completely  
automaticly build the installers. I noticed one issue with that that  
I'll fix in the near future: the current build script for the OSX  
installer relies on the availability of the HTML docs download on the  
Python ftp-site. That dependency should no longer be necessary now  
that the documentation is build using a pure python toolchain.

>
>
> However the "official" OS X images are built, there is an important
> issue about them that should be addressed now.   That issue is which  
> OS
> X versions should be supported by installer images.  (This may well  
> have
> been discussed before so my apologies if I am covering old ground  
> here.)
>
>
>
> The last Apple point release of 10.3 was in 4/2005.  10.4 was also
> released then.  The last Apple maintenance release of 10.4 was in
> 11/2007.  10.5 was released in 10/2007 and, with subsequent update
> releases, remains the current system.  While no release dates have  
> been
> announced, 10.6 (Snow Leopard) is rumored to be nearing release.  If
> Apple follows past practices, they will likely terminate all support  
> for
> 10.4 (release n-2) when 10.6 releases and will continue to support  
> 10.5
> (n-1) for the lifetime of 10.6.  Needless to say, Apple stopped
> supporting 10.3 a long time ago and, if 10.6 does release in the not
> too-distant future, 10.4's days are numbered.

It's not just what Apple supports though, there's also the question of  
what
people actually use.

That said, unless anyone wants to step in to support 10.3 systems I'm in
favour of completely dropping 10.3 support in the binary installers. The
reason for that is twofold: first of all 10.3 is ancient, and more  
importantly
I no longer have access to hardware that will run 10.3 and can therefore
no longer test if 10.3 support actually works.

>
> What does this mean for Python?  To date, there have been no official
> 3.0 OS X installers released.  Because of the deficiencies of building
> for the long-unsupported 10.3 (the distutils bug, the lack of 64-bit
> support, and probably other things I'm not aware of), I think it is  
> very
> important that the 3.0.1 get off on the right foot by changing the
> minimum supported versions now.
>
>
> I see three plausible options:
>
> 1. Release an installer built for 10.5 and higher.
>   pros: delivers 32-support and 64-support;
>   cons: prematurely disenfranchises 10.4 users
>
> 2. Release an installer built for 10.4 and higher.
>   pros: one size fits all
>   cons: no 64-bit support, known bugs in 10.4 wrt locale support, etc
>
> 3. Release two installers, one each for 10.4+ and 10.5+.
>    pros: supports current and future systems;
>           delivers 64-support to 10.5+ users;
>           could choose to drop 10.4 installers anytime after 10.6
>           releases;
>    cons: some extra work to build/release
>             (but not much and not often);
>             others??

I'm in favour of providing two installers: one installer for 10.4 and  
higher that support 32-bit only, and one installer for 10.5 and higher  
that supports ppc, x86 and x86_64.  Ppc64 support could be added as  
well, but only if someone else is willing to support that, I don't  
have reliable access to a ppc64 system for development.  I did notice  
that several libraries, such as libffi (used by ctypes and pyobjc)  
don't work reliably on osx/ppc64.
>
> BTW, over on the pythonmac forum, there has been discussion of having
> some Mac activities at Pycon.  Ronald is planning to be there and I'm
> hoping to, as well, so that could be a great opportunity to discuss  
> and
> work on futures.  And this same discussion and decision needs to be  
> made
> going forward for 2.7 and 2.6.x (I think the change should be made for
> 2.6.2).

I'll be at Pycon and part of post-pycon sprint days (I'm flying back  
on april 1st).  I had already planned to try to get a mac-related  
sprint going at pycon, I've added work on this on the list of possible  
topics.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090214/dbc6c899/attachment-0001.bin>