Investigate providing Tcl/Tk 8.6 with OS X installers

[ned-deily]

BPO	15663
Nosy	@birkenfeld, @rhettinger, @terryjreedy, @kbkaiser, @ronaldoussoren, @benjaminp, @ned-deily, @roseman, @cjrh, @aivarannamaa
PRs	[3.6] bpo-15663: the 10.6+ macOS installers for 3.6/2.7 now provide a private Tcl/Tk 8.6 #11109 [2.7] bpo-15663: the 10.6+ macOS installers for 3.6/2.7 now provide a private Tcl/Tk 8.6 #11110
Dependencies	bpo-1584: Mac OS X: building with X11 Tkinter

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/ned-deily'
closed_at = <Date 2018-02-28.05:43:27.064>
created_at = <Date 2012-08-15.09:20:33.955>
labels = ['OS-mac', 'type-feature', 'expert-installation', 'build', '3.7']
title = 'Investigate providing Tcl/Tk 8.6 with OS X installers'
updated_at = <Date 2018-12-11.09:38:13.466>
user = 'https://github.com/ned-deily'

bugs.python.org fields:

activity = <Date 2018-12-11.09:38:13.466>
actor = 'ned.deily'
assignee = 'ned.deily'
closed = True
closed_date = <Date 2018-02-28.05:43:27.064>
closer = 'ned.deily'
components = ['Build', 'Installation', 'macOS']
creation = <Date 2012-08-15.09:20:33.955>
creator = 'ned.deily'
dependencies = ['1584']
files = []
hgrepos = []
issue_num = 15663
keywords = []
message_count = 34.0
messages = ['168269', '168270', '168271', '178619', '178646', '197055', '197064', '200365', '200501', '200504', '200566', '200693', '201219', '201332', '201413', '202203', '202204', '202207', '202216', '203127', '203987', '248081', '251902', '251909', '251949', '251950', '252034', '260945', '312511', '313047', '315342', '331594', '331596', '331597']
nosy_count = 13.0
nosy_names = ['georg.brandl', 'rhettinger', 'terry.reedy', 'kbk', 'ronaldoussoren', 'benjamin.peterson', 'ned.deily', 'markroseman', 'samueljohn', 'cjrh', 'python-dev', 'Aivar.Annamaa', 'esc24']
pr_nums = ['11109', '11110']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue15663'
versions = ['Python 2.7', 'Python 3.6', 'Python 3.7']

[ned-deily]

The current situation with Tcl/Tk on OS X is less than ideal. The Apple-supplied versions of the Cocoa-based Aqua Tk 8.5 on 10.6 was unusable with IDLE and most Tkinter applications. The 10.7 and 10.8 versions are better but still have serious crashers that have been more recently fixed. python.org installers currently also support using ActiveTcl release but that is also not ideal as there are license restrictions for some users and a separate download and install is required. We should be able to provide a better out-of-the-box experience if python.org installers included its own copies of up-to-date Tcl/Tk libraries (as is the case with the Windows installers). It would be good to still give users the option to use ActiveTcl for any of its additional features or to use system Python. Also we could also look at providing Tcl/Tk 8.5 for 10.5 users (possibly only Intel ones) which we currently do not.

[ronaldoussoren]

A major reason for why the current installers don't install Tk as well is that this would significantly increase the size of the installer.

There's also the question of what bits of Tcl/Tk should be bundled, although I guess we should ship a minimal install of Tk that still supports everything that is wrapped by the python std lib. Alternatively we could ship the same subset as the Windows installer.

[ned-deily]

Yes, it would have to be a subset since some of the stuff in the ActiveTcl releases is unavailable anyway. But the current ActiveTcl installer dmgs are around 24Mb while the 3.3.0 installers are a little less than 20Mb. Even if it were to double the size, 40Mb still seems pretty small by today's standards. And following the Windows installer lead would be a good starting point.

[samueljohn]

Sounds reasonable, but please put the libs not in a place that might conflict with a Tk installed by other means (e.g. homebrew's Tk is a /usr/local).

[ronaldoussoren]

The logical location for installing and embedded Tcl/Tk is either in {sys.prefix}/lib (for a unix install of Tk) or in Python.framework/Versions/X.Y/Frameworks (for a Tcl/Tk framework install).

In either case Tcl/Tk would be installed *inside* Python.framework and hence couldn't conflict with other installations of Tcl/Tk (system, activate-state, homebrew, ...).

Note that this would also make it harder for end users to upgrade Tcl/Tk, currently they can use the ActiveState installer to install a better Tk release and that would no longer be necessary.

That would be a small cost relative to the large gain of having a working Tk release.

[python-dev]

New changeset 985384cd6365 by Ned Deily in branch 'default':
Issue bpo-15663: Tcl/Tk 8.5.14 is now included with the OS X 10.6+
http://hg.python.org/cpython/rev/985384cd6365

[ronaldoussoren]

Great work. Thanks.

[python-dev]

New changeset 7f69f4fadfd8 by Ned Deily in branch 'default':
Issue bpo-15663: Update OS X installer to use Tcl/Tk 8.5.15.
http://hg.python.org/cpython/rev/7f69f4fadfd8

[ned-deily]

I guess the one remaining question about this issue is whether it should be backported to 2.7.x and/or 3.3.x. The implementation depends on the build changes implemented in bpo-1584 to provide options to override default search paths for Tcl and Tk so that would have to be back ported as well. IMO, the entire set of changes are fairly well isolated and should be low risk: basically, they are all build-related changes and mostly isolated to OS X. The primary argument for backporting is that Tk support on current releases of OS X (from 10.6 Snow Leopard on) has been a major pain for our users, such that we have to keep recommending that they install a newer third-party Tcl/Tk to use IDLE or anything else Tkinter-based. So that goes against the batteries-included mission of the python.org installer, especially since the third-party version (ActiveTcl) is not totally free and open source (although it is free as in beer for most uses). On the other hand, one can argue that this is a new feature and thus prohibited in maintenance releases. On the other other hand, one can argue that this is a change driven by changes (or lack thereof) in the underlying OS platform and *essentially* only changes the building of the python.org OS X installer, so it is similar in concept to any other third-party distributor of Python changing an underlying system library. I would be OK with backporting or not but the decision needs to be made by the release managers. Benjamin? Georg?

[benjaminp]

We've upgraded the versions of other embedded libraries in 2.7 bugfix releases, so I'm okay with this for 2.7.