[ python-Feature Requests-1563046 ] MacPython ignores user-installed Tcl/Tk

SourceForge.net noreply at sourceforge.net
Mon Jul 9 09:40:12 CEST 2007 

Feature Requests item #1563046, was opened at 2006-09-21 19:55
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1563046&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Macintosh
>Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Russell Owen (reowen)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: MacPython ignores user-installed Tcl/Tk

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-09 09:40

Message:
Logged In: YES 
user_id=580910
Originator: NO

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.

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2006-09-25 22:43

Message:
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.

----------------------------------------------------------------------

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-23 20:52

Message:
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).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1563046&group_id=5470

More information about the Python-bugs-list mailing list