Re: [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

time for 3.0.1; they are also in py3k and will be going into trunk and

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

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

and tested automatically.  I think that is reasonable and achievable.

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 would like to get to the point where the OS X images can be generated 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

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




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

announced, 10.6 (Snow Leopard) is rumored to be nearing release.  If

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

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.) releases, remains the current system. While no release dates have been 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

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

I no longer have access to hardware that will run 10.3 and can therefore
no longer test if 10.3 support actually works.

It's not just what Apple supports though, there's also the question of what reason for that is twofold: first of all 10.3 is ancient, and more importantly

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

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

support, and probably other things I'm not aware of), I think it is very

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

going forward for 2.7 and 2.6.x (I think the change should be made for
2.6.2).

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

Ronald

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.

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com