NOTE: I suggest making 69182 a duplicate of this bug, not the other way around. That bug is filed with the wrong component. This is a python issue, not a tk issue. Description of Problem: tkinter is not in limbo. This is very sad indeed. Keep in mind that python is a multi-platform language. Even if pygtk is superior to tkinter in nearly all respects, tkinter is still the only widely available cross-platform gui for python. Having tkinter disappear from RedHat makes it very hard to use RedHat as a development platform for cross-platform python applications with guis. Removal of tkinter is a big step. The python2 packages in RedHat 7.3 (and earlier?) included tkinter2. Thus, the disappearance of tkinter for the next RedHat release comes a surprise. I have many applications that use tkinter that I use on a day-to-day basis. I know I'm not alone in this. Restoration of tkinter is very easy. I can't imagine why support was pulled. I feel sufficiently strongly about this that I'm providing a patch to the rpm spec that restores tkinter. I've built and tested this on my limbo system and it seems to work fine. Version-Release number of selected component (if applicable): python-2.2.1-14 How Reproducible: always Steps to Reproduce: 1. run any python application that uses tkinter Actual Results: Tkinter is not there. Expected Results: It should be. Additional Information: To apply my patch, install the python-2.2.1-14 source RPM and apply this patch with patch -p0 from the /usr/src/redhat directory (or wherever the parent of your SPECS directory is). You may also remove the obsolete Python-2.2.1-pydocnogui.patch file from SOURCES. I've included a changelog entry and updated the release to 14.1. You'll obviously want to fix this in whatever way is suitable to your procedures.... I hope you will give strong consideration to my request. I think I've presented compelling arguments why Tkinter should not be yanked, especially without warning. Even python.org declares that Tkinter is the defacto standard gui package for Python. Removing it from RedHat significantly decreases RedHat's viability as a cross-platform Python development system. I notice that limbo doesn't install tk or tix by default. I think it's okay if it doesn't install tkinter by default either, if you insist. I've tested my new rpms with and without tkinter present, so my solution does not preclude removal of tkinter by default while still allowing it to be present for those who want to use it. Thank you for your consideration.
Created attachment 69124 [details] patch to python rpm spec to restore tkinter
I've added teg to the cc of this bug report since his name appears in the changelog as having removed tkinter.
*** Bug 69182 has been marked as a duplicate of this bug. ***
*** Bug 68845 has been marked as a duplicate of this bug. ***
Concur on retention of Tk and Tkinter ... these are really mandatory in a modern (or at least recent) *nix system, as basic tools. The cross-enabling hooks for Python are obvious and needful. It is lightweight, mature, and small -- under 1 meg. <advert> I package and carry from CPAN: perl-Tk -- which I rather like at: ftp://www.herrold.com/pub/local/ORC/perl-Tk/ -- a bit fatter at 2 M
Dave -- Your comments on COLUG list and experience as a CS professor at Capital University and the recent study you mentioned there on curriculum switch from C++ to Python cross platform, may be useful in recap here.
It's back for now, but Tk is a dying widget set - python mixes very well with gtk+. (python-2.2.1-15)
I agree that Tk is not a particularly nice widget set to use - I don't write software using it myself (I use pygtk), but it does appear to be the most common cross-platform widget set for Python. There appears to be growing interesting in using Python at the college level in CS1. At the ACM Computer Science Education conference earlier this year I spoke with a number of profs already using Python and a number of profs who were considering the change. I know of at least two books that have textbooks for Python that have come out recently and they of course use Tk in their examples. And of course many non-textbook Python books include Tk examples. Thanks for putting it back in. Most of our freshman students start with Windows but a number of them switch to Linux (usually Red Hat since I tell them that's what I use) once they get on campus so this will make it easy for them to do their assignments and try out the book Tk examples on their computers.
Thanks a lot for adding it back in. It's gratifying to see democracy in action. The fact that Red Hat gives people opportunities to express their views during the beta period and then actually listens to those views is part of what makes Red Hat's release so good, and why I've been using it since version 2.1 (prior to which I used to "roll my own"). Please consider when you say that Python mixes well with gtk and that Tk is a dying widget set that there is a lot of code out there that uses Tk and Tkinter, and that gtk doesn't exist on as many platforms as Tk does. If you do in fact plan on eventually phasing out Tkinter, I'd strongly suggest that this decision be mentioned in the release notes. Even if one accepts that assertion that Tk is a dying widget set, that in itself doesn't seem to justify pulling it out. Sure, it's old and a bit crufty, but Xaw is even worse, and we don't get rid of that. We also keep twm around. It's important to have some light-weight tools that work in simple environments. Even make xconfig for the kernel uses tk. That isn't to say that thare may not be some good reasons to pull Tk. If it's getting hard to compile or interferes with a lot of other more important software, then I could understand pulling it out. But as long as it's easy to keep around, why kill it? It doesn't take up much space, and it's still easy to compile and install. However, if there are compelling reasons to get rid of it, please do it in a "responsible" way as RedHat so often does very well. Announce that it is being deprecated in the release notes and in the package information in the rpm. Suggest alternatives or provide a migration path. (Okay, providing a migration path is out of scope.) Make both tk and tkinter not installed by default (as you are already doing with Tk in limbo). That way, in order to get Tk and Tkinter, people will have to go through specific steps (unless they install Everything). Then, if we complain when the beta for RedHat 9 comes out, we won't have as much of a leg to stand on. I know this whole episode has convinced me to find an alternative to my Tkinter stuff, but I'm very pleased to know that I have another release cycle to do this at my leasure rather than having to drop everything and do it now or else miss out on the beta testing. (Some of my day-to-day use items depend upon Tkinter.) I have an open bug report with release notes suggestions (bug 70845). I'll repeat my release notes suggestions there. Thanks again for restoring Tkinter, even if only temporarily.