Ubuntu package "python3" does not include tkinter

[Steven D'Aprano]

On Mon, 22 Apr 2013 14:52:39 +0200, Antoon Pardon wrote:

> Op 22-04-13 11:18, Steven D'Aprano schreef:
>> On Mon, 22 Apr 2013 03:08:24 -0500, Andrew Berg wrote:
>>
>>> Much of the stdlib doesn't rely on anything but the core interpreter.
>>> tkinter by itself is not the issue. As you said, the bindings are
>>> tiny. However, in order to be usable, it requires quite a few things -
>>> most notably X. On desktop Linux, this is already installed, but on
>>> server systems, it generally is not (or at least shouldn't be in most
>>> cases). Going back to my example of a web server using a Python-based
>>> framework, I'll repeat that there is no reason such a system should
>>> have X even installed in order to serve web pages. Even on a lean,
>>> mean server machine, CPython requires only a few extra libraries. Add
>>> tkinter, and suddenly you have to install a LOT of things. If you plan
>>> to actually use tkinter, this is fine. If not, you've just added a lot
>>> of stuff that you don't need. This adds unnecessary overhead in
>>> several places (like your package system's database).
>> I can't disagree with any of this, except to say that none of this
>> justifies having a separate package for Tkinter. Naturally if you don't
>> have X, Tcl won't work, and if Tcl won't work, Tkinter won't work and
>> should give an import error. But that doesn't imply that X must be a
>> dependency for Python. It's a dependency for having Tkinter *work*, but
>> not for *installing* Tkinter as part of the standard library.
>>
>> Hell, even if you have X installed, and Tcl, and the Tkinter packages,
>> importing tkinter can still fail, if Python wasn't built with the right
>> magic incantations for it to recognise that Tcl is installed.

> Then don't use a package system. The job of a package system is, that if
> you install something, it install all dependencies that are needed to
> make it work.

No, the job of the package system is to manage dependencies. It makes no 
guarantee about whether or not something will "work".

$ sudo apt-get install rule_world
$ rule_world --start-from Australia
Error: cannot connect to US nuclear arsenal from here, you cannot rule 
the world


A joke example, of course, but a serious point. Successful installation 
doesn't necessarily mean the program will run successfully, or "work" in 
any meaningful way.

We're also glossing over what it means to be a dependency. This is not 
obvious, and in fact I would argue that X is NOT a dependency for 
tkinter, even though tkinter will not "work" without it, for some 
definition of work. I can quite happily import tkinter on a remote 
machine over ssh:

py> from tkinter.messagebox import showinfo

or do the same thing on a local machine from a non-X terminal. I haven't 
tried it, but quite possibly even on a headless machine without X 
installed at all. And why not? Tkinter is a big module, there are all 
sorts of things that I might want to access that don't actually require 
an X display. If nothing else, I can do this:

py> help(showinfo)


and read the docs. Tkinter does not actually require X to "work". It 
merely requires X in order to *display an X window*.

It's only when I actually try to do something that requires an X display 
that it will fail. I won't show the entire traceback, because it is long 
and not particularly enlightening, but the final error message explains 
exactly why it isn't working:

_tkinter.TclError: no display name and no $DISPLAY environment variable



> Your solution doesn't make sense in view of your earlier response where
> you argue tkinster should be installed because it is part of the
> standard combined with the advantage of having a standard library. But
> IMO a part of that standard library not working, is just as harmful as
> part of that standard library not being installed. From a
> user/programmer's point of view the result is the same. It is unusable.

Not at all. As I said earlier, I would expect that trying to import 
tkinter on such a system should give a meaningful error message. 
Actually, it need not even fail at import time. As I show above, I can 
happily import tkinter without an X display. I haven't tried it, but I 
expect that I can probably import tkinter without Tcl either.

Let me put this another way:

It should not matter whether I install Tcl before Python, or after 
Python, the end result should be that once both are installed, tkinter 
will be usable (provided you have an X display). To put it in Ubuntu 
terms, if I do this:

apt-get tcl
apt-get python

or this:

apt-get python
apt-get tcl

on a machine with X, tkinter should Just Work. And if I don't install 
tcl, tkinter should still import, it just won't be able to, you know, 
interface to tcl.

What we're arguing here is merely the design of the dependency graph, and 
that's a matter of taste. My design would be different from that of the 
Ubuntu folks. That's fine. If we all agreed about everything, we'd have 
nothing to argue about *wink*

But I think we can all agree that something like this is pretty crappy:


py> import Tkinter
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.5/lib-tk/Tkinter.py", line 38, in <module>
    import _tkinter # If this fails your Python may not be configured for 
Tk
ImportError: No module named _tkinter

Oh great. My Python is not configured for Tk. How does that help me? What 
do I do now? No idea. Why oh why can't we get a better class of error 
messages?




-- 
Steven