MacPython ignores any user-installed Framework Tcl/Tk. This is a 
significant issue for Tcl/Tk users because the Tcl/Tk included with 
Tiger is buggy and really shouldn't be used.

Bob Ippolito supplied me a recipe to fix _tkinter.so:
install_name_tool \
     -change /System/Library/Frameworks/Tcl.framework/Versions/8.4/
Tcl \
             /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl \
     -change /System/Library/Frameworks/Tk.framework/Versions/8.4/
Tk \
             /Library/Frameworks/Tk.framework/Versions/8.4/Tk \
     _tkinter.so

I encapsulated this recipe into the attached python script "fixtkinter.py", 
which modifies _tkinter.so to use the user's Tcl/Tk, if found.

Please consider running this script while installing MacPython. If you 
want any refinements to the script, I am happy to provide them (or feel 
free to modify it yourself of course).

Subtleties:
- The script uses Carbon.Folder.FSFindFolder to find the "/Library/
Framework" directory, so it should work in any country.
- The script fixes the _tkinter.so for the python that executes the script 
(finding it relative to the "os" module).
- The script silently exits without doing anything if no /Library/
Framework Tcl/Tk is found. Thus it is safe to run for all MacPython 
installations.
- It can safely be run more than once; it silently does not modify 
_tkinter.so file the second time.
- It finds the link using ...Tcl.Framework/Versions/Current but resolves 
the link before modifying _tkinter.so. So if a user upgrades a major Tcl/
Tk version the _tkinter.so file will keep using the old version. I think this 
is a good thing, since compatilibility is likely to be an issue.
- It only looks for a user-installed Tcl/Tk in "/Library/Frameworks"; it 
does NOT look in the user's private library (~/Library). This was 
intentional, but I'm not sure it was the right decision. I'm happy to 
change it, but will want some advice on the best algorithm.

Logged In: YES 
user_id=580910

If this gets used (and that's a big if at the moment) it should not look in the 
users private library folder, because the system might be used by multiple 
users and a system wide install should not use files that happen to be in the 
home directory of one of them.

I don't like using this script during installation but would prefer a slightly 
different solution: ship this script in /Applications/MacPython 2.5 and tell 
users about it in our documentation (the installer documentation, the 
pythonmac.org FAQ and possibly the tkinter docs).

If Tiger's copy of Tk is really bad enough to avoid using it completely we 
should find a way to ship a minimal copy of Tcl/Tk with our installer (installed 
into /Library/Frameworks/Python.framework/Versions/2.5/Frameworks/
{Tcl,Tk}.framework), again with your script installed in the applications folder 
for people that want to use a bleeding edge copy of Tk.

I'm not to keen on automaticly using the copy of Tk in /Library/Frameworks 
because of the support issue this raises: it is hard enough to debug problems 
as it is without users haveing slightly different library versions.


BTW. Carbon.Folder.FSFindFolder is a nice touch but not actually necessary, /
Library/Frameworks is named like that in all languages, the name you see in 
the Finder might be different but that's because the Finder localizes the 
names of a number of folders (hence the ".localized" file in a number of 
folders).

Logged In: YES 
user_id=431773

I see what you mean about different installations. I think the following might 
work better:
- Always modify _tkinter.so to point to Tcl/Tk 8.4 in /Library/Frameworks. 
This will fall back to the built in /System/Library/Frameworks if the user has 
not installed an 8.4 of their own.

It avoids a few of the issues you bring up and is simpler and more robust than 
what I originally suggested. Advantages:
- All installations would be the same.
- If the user installs a new Tcl/Tk after installing Python, it would be used 
(unless it's 8.5, which would not be safe to try with Python).

It still does not address your concern than a user might accidentally have a 
Tcl/Tk that they don't want to use. I'd personally be happier if users could 
easily upgrade their Tcl/Tk (since the installed one is so bad), so I see this as 
more of an advantage than a disadvantage. Users aren't going to typically 
install Tcl/Tk unless they want to use it, I think. Still...I'm sure you've seen 
more requests for help than I have over the years.

I'm not keen on including a Tcl/Tk for several reasons:
- It can be tricky to add needed additions (my app uses the "snack" sound 
library, for example). A standard Tcl/Tk makes this much easier (and in fact 
ActiveState Tcl/Tk already includes all additions most folks would want).
- There is no universal Tcl/Tk yet (though one is planned). I personally don't 
want to try to build one.
- Which version would you use? Even 8.4.11 has some important known bugs, 
and 8.4.13 has different ones (at least one of which is very nasty for my 
application, so I stick with 8.4.11 for now).

So my personal suggestion is that we modify _tkinter.so using Bob Ippolito's 
recipe unchanged (no fancy script that hunts for an installed Tcl/Tk). It will be 
completely compatible with the built in Tcl/Tk but gives any real users of Tcl/
Tk (anyone who isn't just writing "hello world") a trivial way to get a decent 
version.

I also suggest ditching the python script (or simplifying it to just institute 
Bob's recipe, but a shell script probably makes more sense for that job).

Note that Bob's recipe is in the comments at the top of my python script.

Thanks for the note about /Library/Frameworks. I had no idea it was a 
universal name.

Current builds of python look in /Library and /System/Library (in that order). IMHO that is good enough(tm), as that's where one would expect Tcl/Tk to be unless a really savy user did a manual install from source.

I don't like shipping the proposed fix module, IMHO it would be better to publish that somewhere else (such as the python cookbook) as scripts like this will otherwise likely be overlooked. Changing the link path should also not be necessary with current builds of python.