_tkinter and Tcl/Tk versions
Hi! Guido van Rossum:
Modified Files: FixTk.py Log Message: Work the Tcl version number in the path we search for. [...] ! import sys, os, _tkinter ! ver = str(_tkinter.TCL_VERSION) ! v = os.path.join(sys.prefix, "tcl", "tcl"+ver) if os.path.exists(os.path.join(v, "init.tcl")): os.environ["TCL_LIBRARY"] = v [...]
Just a wild idea: Does it make sense to have several incarnations of the shared object file _tkinter.so (or _tkinter.pyd on WinXX)? Something like _tkint83.so, _tkint82.so and so on, so that Tkinter.py can do something like the following to find a available Tcl/Tk version: for tkversion in range(83,79,-1): try: _tkinter = __import__("_tkint"+str(tkversion)) break except ImportError: pass else: raise Of course this does only make sense on platforms with shared object loading and if preparing Python binary distributions without including a particular Tcl/Tk package into the Python package. This idea might be interesting for Red Hat, SuSE Linux distribution users to allow partial system upgrades with a binary python-1.6.rpm Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
Guido van Rossum:
Modified Files: FixTk.py Log Message: Work the Tcl version number in the path we search for. [...] ! import sys, os, _tkinter ! ver = str(_tkinter.TCL_VERSION) ! v = os.path.join(sys.prefix, "tcl", "tcl"+ver) if os.path.exists(os.path.join(v, "init.tcl")): os.environ["TCL_LIBRARY"] = v [...]
Note that this is only used on Windows, where Python is distributed with a particular version of Tk. I decided I needed to back down from 8.3 to 8.2 (8.3 sometimes crashes on close) so I decided to make the FixTk module independent of the version.
Just a wild idea:
Does it make sense to have several incarnations of the shared object file _tkinter.so (or _tkinter.pyd on WinXX)?
Something like _tkint83.so, _tkint82.so and so on, so that Tkinter.py can do something like the following to find a available Tcl/Tk version:
for tkversion in range(83,79,-1): try: _tkinter = __import__("_tkint"+str(tkversion)) break except ImportError: pass else: raise
Of course this does only make sense on platforms with shared object loading and if preparing Python binary distributions without including a particular Tcl/Tk package into the Python package. This idea might be interesting for Red Hat, SuSE Linux distribution users to allow partial system upgrades with a binary python-1.6.rpm
Can you tell me what problem you are trying to solve here? It makes no sense to me, but maybe I'm missing something. Typically Python is built to match the Tcl/Tk version you have installed, right? --Guido van Rossum (home page: http://www.python.org/~guido/)
Hi! [me]: [...]
particular Tcl/Tk package into the Python package. This idea might be interesting for Red Hat, SuSE Linux distribution users to allow partial system upgrades with a binary python-1.6.rpm
Can you tell me what problem you are trying to solve here? It makes no sense to me, but maybe I'm missing something. Typically Python is built to match the Tcl/Tk version you have installed, right?
If you build from source this is true. But the Linux world is now different: The two major Linux distributions (RedHat, SuSE) both use the RPM format to distribute precompiled binary packages. Tcl/Tk usually lives in a separate package. (BTW.: SuSE in their perverse mood has splitted Python 1.5.2 itself into more than half a dozen separate packages, but that's another story). If someone wants to prebuild a Python 1.6 binary RPM for installation on any RPM based Linux system it is unknown, which version of Tcl/Tk is installed on the destination system. So either you can build a monster RPM, which includes the Tcl/Tk shared libs or use the RPM Spec file to force the user to install a specific version of Tcl/Tk (for example 8.2.3) or implement something like I suggested above. Of course this places a lot of burden on the RPM builder: he has to install at least all the four major versions of Tcl/Tk (8.0 - 8.3) on his machine and has to build _tkinter four times against each particular shared library and header files... but this would be possible. Currently the situation with SuSE Python 1.5.2 RPMs is even more dangerous, since the SPEC files used by SuSE simply contains the following 'Requires'-definitions: %package -n pyth_tk Requires: python tk tix blt This makes RPM believe that *any* version of Tcl/Tk would fit. Luckily SuSE 6.4 (released last week) still ships with the old Tcl/Tk 8.0.5, so this will not break until SuSE decides to upgrade their Tcl/Tk. But I guess that Red Hat comes with a newer version of Tcl/Tk. Hopefully they have got their SPEC file right (they invented RPM in the first place) RPM can be a really powerful tool protecting people from breaking their system with binary updates --- if used the right way... :-( May be I should go ahead and write a RPM Python.SPEC file? Would that have a chance to get included into src/Misc? Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
RPM can be a really powerful tool protecting people from breaking their system with binary updates --- if used the right way... :-(
May be I should go ahead and write a RPM Python.SPEC file? Would that have a chance to get included into src/Misc?
I'd say yes! But check with Oliver Andrich first, who's maintaining Python RPMs already. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
artcom0!pf＠artcom-gmbh.de -
Guido van Rossum -
pf＠artcom-gmbh.de