Piet van Oostrum (on python-dev and elsewhere) wrote:

I tried to install matplotlib 1.3.1 on the release candidates of Python 2.7.6 and 3.3.3.
I am on Mac OS X 10.6.8.
Although the installation gave no problems, there is a problem with Tcl/Tk.

The new Pythons have their own embedded Tcl/Tk, but when installing matplotlib it links to the Frameworks version of Tcl and TK, not to the embedded version. This causes confusion when importing matplotlib.pyplot:

objc[70648]: Class TKApplication is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined.
objc[70648]: Class TKMenu is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined.
objc[70648]: Class TKContentView is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined.
objc[70648]: Class TKWindow is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined.

And then later it gives a lot of error messages.

So I think it should be linked to the embedded version. For this the matplotlib setupext.py should be adapted to find out if there is an embedded Tcl/Tk in the Python installation and set the link parameters accordingly. However, the installed Python versions (from the DMG's) do not contain the Tcl/Tk header files, only the shared library and the tcl files. So I thing the distributed Python should also include the Tcl/Tk header files.

https://mail.python.org/pipermail/python-dev/2013-November/129993.html

That's unfortunate.  It looks like matplotlib on OS X (darwin) has cpp code that interfaces directly with Tk and, hence, needs Tk headers.  Further, for OS X (darwin), its setup.py assumes that Tkinter is linked with Tcl and Tk installed as frameworks in /Library/Frameworks (for third-party installs) or /System/Library/Frameworks (the Apple-supplied ones).  It also appears that matplotlib borrowed these assumptions from PIL (the Python Imaging Library project) and which have been carried into its fork, Pillow.

The current implementation of the built-in Tcl/Tk for the python OS X installers was designed to be standalone for Tkinter's use only.  So it currently does not install Tcl and Tk header files.  It also does not install Tcl and Tk into /Library/Frameworks so that it will not conflict with existing installations, like from ActiveState, that might have additional packages installed for real Tcl/Tk applications.  As Piet noted for matplotlib, just including header files would not by itself solve the problem for these projects.  Their setup*.py files would need to change as well to understand the new locations. (Sidenote: I see that at least one of the third-party OS X packagers, MacPorts, has a similar problem and patches these files in order for their ports of these projects to use the MacPorts-installed Tcl and Tk.)

In anticipation of some problems like this, the rc1 installers ship with two versions of _tkinter.so: one linked with the new built-in Tcl/Tk libs and the other linked as before with Tcl and Tk frameworks in /Library/Frameworks falling back to /System/Library/Frameworks.  The latter _tkinter.so is not on the default search path.  It is possible for the user administrator to change the installation to always use the old-style _tkinter.so by copying it into lib-dynload.  This is documented, although rather obscurely, in the installer BuildScript README.  It is also possible to dynamically override at execution time by manipulating the Python search path, either by setting PYTHONPATH or prepending to sys.path the path to the directory with old-style _tkinter.so.  This is even more obscurely documented.  The hope was that neither would be routinely needed except by expert users for some corner cases.  But matplotlib and PIL/Pillow do not fit that category.

There are various options. I want to ponder them for a bit; I'll have an update within 24 hours.

After further investigation and deliberation, I believe that we need to revert the built-in Tcl/Tk from the OS X installers for 2.7.6 and 3.3.3.  The contributing factors:

1. As implemented, we now know that the built-in Tcl/Tk breaks source installs and/or binary package installers for PIL/Pillow, matplotlib, and, by extension, pandas.  These are all widely-used projects and are important customers of the OS X 10.6+ installers.

2. With the recent release of OS X 10.9 Mavericks, there is now a critical problem (Issue18458) preventing interactive use of the current maintenance release installers (3.3.2 / 2.7.5) on 10.9.  New releases are needed as soon as possible to provide fixes for this, a few less critical 10.9 issues, and general bug and security fixes for all platforms.  So it is not appropriate to delay 3.3.3 or 2.7.6 to attempt to fix the incompatibility issue.  (Fixing the built-in Tcl/Tk for 3.4.0b1 or for future maintenance releases are separate open items to be tracked on Issue15663.)

3. Updated Tcl/Tk 8.5 installers for OS X are now available from ActiveState (8.5.15.1) which include the Tk patch for the 10.9 "screen refresh" problem originally seen with IDLE and patched in the built-in Tks of the 2.7.6rc1_rev1 and 3.3.3rc1_rev1 installers.

One positive outcome of this is that we are more aware of the interdependencies of some of the projects using the python.org installers.  As a result, I am adding to the python.org OS X installer testing and release processes additional "quicklook" regression testing using some of these projects so we have a better chance of catching issues like this one earlier.

Another positive is that it shows that there are members of the community who are taking the time to try pre-releases and that such testing *is* really important.  Thank you to all of you who have been doing so and reporting issues.  And a particular thank you to Piet for calling attention to this one.

I think future versions of Python should add the relevant information about how they are linked to Tcl/Tk in sysconfig. This would include the path of the include files, the shared libraries and the tcl files. Or a framework location on OS X if this is used. The setup.py for extensions that need to link to Tcl/Tk can then interrogate this information, and fall back to the current way, if it is not available.

Piet, yes, I've been thinking of how to do that.  Unfortunately, it can only be a hint since, in the case of an "installer" Python, there is no guarantee that the header files on the build machine are available on the installed machine in the same location or even at all.

Downgrading, since this is "fixed" in release branch.

As proposed above, the built-in Tcl/Tk support has been reverted from the OS X installers for 3.3.3rc2 and for 2.7.6 final.  Issue15663 will continue to track changes for 3.4.0; the implementation there will have to change for 3.4.0b1. I've also opened Issue19558 concerning Piet's suggestion to provide a way to obtain info about Tcl and Tk linkage.  This issue can now be closed.