This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ned.deily
Recipients benjamin.peterson, georg.brandl, larry, ned.deily, pietvo
Date 2013-11-04.09:37:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1383557829.26.0.523796226452.issue19490@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2013-11-04 09:37:09ned.deilysetrecipients: + ned.deily, georg.brandl, larry, benjamin.peterson, pietvo
2013-11-04 09:37:09ned.deilysetmessageid: <1383557829.26.0.523796226452.issue19490@psf.upfronthosting.co.za>
2013-11-04 09:37:09ned.deilylinkissue19490 messages
2013-11-04 09:37:07ned.deilycreate