In article <48c14e26-e790-47c2-bd44-fc65159d8...@zope.com>, Zvezdan Petkovic <zvez...@zope.com> wrote: > Why do we make 10.4 or even 10.3 the default target for Mac builds of > Python any more? Moving the default to 10.5 would be better, IMHO.
That's a good question and now is a good time to have a discussion about it again. I think the primary reason to use 10.3 was to try to maximize the range of supported OS X version while minimizing the number of installer images that need to be built, tested, and maintained. It takes a fair amount of work to do this and it's not like there is a full-time, paid staff to do any of it. And so far it has worked pretty well. (Thanks be to Ronald!) A potential secondary value is to make it easier for package maintainers to supply binary distributions (including via PyPi) for packages with C extension modules. In theory, right now one should be able to supply one bdist_egg that would work for the python.org 2.6 (say) on any of 10.3 to 10.6, obviating the need for the end user to install Xcode just to install the package. I'm not sure that actually works in practice because the version testing in setuptools/Distribute needs to take into account the special multi-version arch names (e.g. "fat", "universal", etc). Plus, different eggs would still be needed to support the Apple-supplied python(s). So, this may be a nice goal but probably needs more work and guidance for package maintainers to achieve maximum benefit for users. It might be a good project for someone to take on. That said, with the introduction of wide-spread 64-bit support in 10.5, there's been a long standing desire to have an officially-supported 64-bit variant available on python.org. For 10.5, Ronald added a "universal" option to the build infrastructure that creates a 4-way build (ppc 32-bit, ppc g5 64-bit, intel 32, intel 64). It works on 10.5 but there are some rough edges yet: no out-of-the-box 64-bit Tk on 10.5 so no Tkinter in 64-bit mode; most of the old (and deprecated) Macintosh modules fail in 64-bit mode because of Apple's decision to not provide full Carbon 64-bit support; documentation needed for 64-bit support, etc etc. Another rough edge has been the lack of easy access to a G5 for ad-hoc testing of ppc-64. A 4-way universal build on 10.5 can be useful as it stands but more work needs to be done to be able to release a batteries-included installer with 64-bit support at the same level of quality as the current 2-way 32-bit-only one. (A side note: there are fewer 64-bit issues for Python 3.x because the problematic Macintosh modules don't exist there.) The picture changes for 10.6. For one, although the ppc-32 variants of the relevant system frameworks and libraries are still supplied, ppc-64 no longer are. There is also an Apple-supplied 64-bit version of Tk 8.5 (although there is at least one ugly unresolved issue at the moment when IDLE/Tkinter is built with it). For these and other reasons, Ronald added a "3-way" build option (no ppc-64) and we've talked about providing a second installer image per release: a 3-way variant with a deployment target of 10.5 which would provide 32-bit (ppc/intel) and intel-64 support for 10.5 and 10.6. But, after some extended exposure to 10.6 and observing some of the issues people have been running into with installing modules, I've changed my mind about this and now would recommend that, for python.org, we officially support 64-bit starting with 10.6, rather than 10.5. That is, continue to supply the 10.3-on-up 32-bit ppc/i386 variants for the foreseeable future and aim to add a second installer (for 2.6.x and 3.1.y) that is built 2-way-intel-only (32/64) with a deployment target of 10.6. Why not 10.5, too? One, there is the lack of official 64-bit Tk support on 10.5. That complicates the installer build; either don't support Tk in 64-bit mode if built on 10.5 or build on 10.6 and add some checks when running or installing on 10.5. It's not an insurmountable problem although there would still be no 10.5 64-bit Tkinter without a possible dependency on 3rd-party frameworks. A more serious problem, I think, is the -arch ppc dependency for extension modules on 10.6. A significant number of popular packages on PyPi are ones that provide wrappers of various sorts to 3rd-party C libraries not provided with OS X or possibly depend on versions newer than those supplied with the OS X release. MySQLdb and PIL are examples of the first case, lxml of the second. By mandating a 3-way architecture on 10.6, when installing packages distutils will try to build all three architectures and, unless the user has gone to the unnecessary trouble of installing at least a 3-way version of the dependent libraries, the extension build/install will likely emit troublesome warning messages like: ld: warning: in /opt/local/lib/mysql5/mysql/libmysqlclient_r.dylib, missing required architecture ppc in file or, in hypothetically more complex builds, actually fail to build. Again, that could probably be fixed in distutils: don't build ppc on 10.6 by default, as long as there was some way to override that when building distributions intended for 10.5. But is it worth the added complexity? Another hypothetical issue, as Zvezdan alludes to, is the differences in functionality between releases. Certainly there are important differences at the framework API level between 10.4 and 10.5. No doubt there are ones yet to be discovered between 10.5 and 10.6. Many of the 3rd-party libraries supplied with OS X are updated for 10.6. And there's no question that 10.5 is the end of the line for PPC support. For all of these reasons, and I'm sure we can all come up with others, I now think it makes most sense to move forward for 64-bit support starting with 10.6. That's not good news for 10.5 users seeking official 64-bit support but they have been on their own this long anyway. And, presumably, most of the Intel-64 users will be motivated to move to 10.6, sooner or later. The "stuckees" here are the ppc G5 users but, alas, they would not get 64-bit support under the 3-way option anyway. So, to summarize, I suggest that we continue to provide the current style of 10.3+ 32-fat installers for 2.m.n and 3.x.y for the indefinite future and that we work towards providing a second installer for 2.m.n and 3.x.y (m, n, x, y TBD), providing 10.6+ intel 32/64 support. If that seems reasonable to everyone (and, particularly, to Ronald), perhaps we should open a tracker issue (more a meta-issue) towards that end. Comments welcome! -- Ned Deily, n...@acm.org _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
