In article <
48C14E26-E790-47C2-BD44-FC65159D8D03@...>,
Zvezdan Petkovic <
zvezdan@...> 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,
nad@...
_______________________________________________
Pythonmac-SIG maillist -
Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig
makefail.log (6K) 