Ubuntu package "python3" does not include tkinter

[Steven D'Aprano]

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.

 

[rusi]

If your friend believes that having to do an extra pair of clicks or typing
sudo apt-get install python-tk is an unbeatable hurdle then your friend's
computer skills are awfully lacking and he won't have much success learning
how to write programs.

There are two worldviews here and they are as far as far can be. Its
good to see them before arguing.
1. python as a standalone language
2. python as part of an (OS-related) ecosystem

In windows python may or may not exist. And if it exists and I go
inside the python directories and start messing around -- deleting
some files, modifying others etc -- what will happen? Nothing much. My
python programs will stop working.
Presumably if I reinstall, it will be fine thereafter.

What about linux?
As an experiment I just tried
$ aptitude purge python
#Noobs BEWARE of that command
and aptitude was too confused to give me a coherent report

Tried then
$ aptitude purge python2.7
The list of packages that it would purge was in hundreds. Heres a
small sample of what would go:
Firstly there are all the python-* packages. This is obvious. Not so
obvious that some like python-csound were probably installed by me.
Others like python-debian are needed for the basic health and
functioning of the system.

And besides these there are a pile of others that have no relation to
python. A sample:
asciidoc, bzr, dia, eog, gcj-*, gdb(!!), gimp, gnome-* (about 20 of
these) printconf…

So python is completely optional in windows.
It is a part of the infrastructure on linux
Messing with it is almost like saying: "I dont see what that vmlinuz
file is doing in /boot. So I removed it."

Coming to the OP question:
a. The python that PSF provides is suitable for learning python
b. The python that linux distros provide is part of the wireframe on
which the system rests.

b may be derived from a but they are hardly the same. They may look
very similar but their intents are quite different.

So when you say

If your friend believes that having to do an extra pair of clicks or typing
sudo apt-get install python-tk is an unbeatable hurdle then your friend's
computer skills are awfully lacking and he won't have much success learning
how to write programs.

Its all correct what you say. You wont have too many people learning
from you if thats how you say it.
Remember that the difference between an expert and a noob is rarely a
question of intelligence or diligence.
Its just some boring trivial mountain of data that the expert has
picked up over time

 

[lcrocker]

No one actually has to install tkinter.  That's the whole point of providing
it as a separate package: only those who want to use it have to install it.
The rest of us don't.

I'm a programmer, I installed Tkinter, and use it. I'd like to deploy
programs
written with it to others. **Those** people know nothing about it,
and
**shouldn't have to**. I've given them a program in Python, they have
Python,
but it doesn't run, and doesn't give them a helpful error. They'll
probably
just blame me and move on. Not every Python user is a programmer. If
I write
a program in Java, any user with Java installed can run it. As it
stands,
that's no true for Python. That's not good PR for the cause.

 

[rusi]

I'm a programmer, I installed Tkinter, and use it. I'd like to deploy
programs
written with it to others.  **Those** people know nothing about it,
and
**shouldn't have to**. I've given them a program in Python, they have
Python,
but it doesn't run, and doesn't give them a helpful error. They'll
probably
just blame me and move on.  Not every Python user is a programmer.  If
I write
a program in Java, any user with Java installed can run it.  As it
stands,
that's no true for Python.  That's not good PR for the cause.

On the whole agree -- except for the java part -- maybe you've not
heard of 'jar hell'?
On the whole easy-deployability without losing easy-programmability is
a major research issue.

See this for someone choosing C++ over Lisp
http://comments.gmane.org/gmane.comp.finance.ledger.general/1955

 

[Antoon Pardon]

Op 22-04-13 11:18, Steven D'Aprano schreef:

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. And if, as the OP you thinks, python working, means tkinter working,
not installing tcl and not installing X, is not an option.

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.

 

[Chris Angelico]

I'm a programmer, I installed Tkinter, and use it. I'd like to deploy
programs
written with it to others. **Those** people know nothing about it,
and
**shouldn't have to**. I've given them a program in Python, they have
Python,
but it doesn't run, and doesn't give them a helpful error. They'll
probably
just blame me and move on. Not every Python user is a programmer. If
I write
a program in Java, any user with Java installed can run it. As it
stands,
that's no true for Python. That's not good PR for the cause.

If you're deploying only to Debian-based Linuxes (such as the Ubuntu
you mentioned originally), then it may be worth distributing your
program as a .deb file and declaring all the appropriate dependencies
(which would then include python3-tk). Alternatively, just put an
"apt-get install python3-tk" into your install script (which is what I
do for internal deployments - if you need package XYZ for program Foo,
inst-foo will install XYZ), or simply tell people they need to install
it. How do you make sure they even have a Python 3.x? Whatever you do
to ensure that, just add python3-tk to it.

ChrisA

 

[Rui Maciel]

I'm a programmer, I installed Tkinter, and use it. I'd like to deploy
programs written with it to others. **Those** people know nothing
about it, and **shouldn't have to**.

They don't need to. The only person that needs to know what he is doing is
you. You want to distribute a software package? Package it. Learn the
very basics and set python-tkinter as a dependency.

http://wiki.debian.org/Packaging


Rui Maciel

 

[Rui Maciel]

I think that if you are worrying about the overhead of the tkinter
bindings for Python, you're guilty of premature optimization.

I'm not worried about that. No one should be forced to install crap that
they don't use or will ever need, no matter how great the average HD
capacity is nowadays.


Rui Maciel

 

[Steven D'Aprano]

I'm not worried about that. No one should be forced to install crap
that they don't use or will ever need, no matter how great the average
HD capacity is nowadays.

Nobody forces you to do anything. Python is open source, and the source
code is freely available. Feel free to hand-optimize your Python
installation, selecting carefully each and every module, class, and
function in the standard library so that only the ones you absolutely
know you will need to use are installed, using your godlike powers of
precognition to foresee exactly what you need in seventeen months from
now and what is "crap" that you will never need.

Good luck with that. I look forward to hearing about the results.

 

[Steven D'Aprano]

Op 22-04-13 11:18, Steven D'Aprano schreef:

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?

 

[Chris Angelico]

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

You presumably have a system to test this on. Can you try using ssh -X
to get to it, and then retry that action? It looks like you actually
have everything you need, just no display... which is exactly what
you'd get if you ssh to something that has a real GUI. Not a
dependency problem.

ChrisA

 

[Andrew Berg]

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

So you want to go from "this won't work because it's not installed" to "this won't work, and it there could be a hundred different reasons
why"? tkinter's main function is to display something on a display. To say that displaying something is an optional feature is absurd.
"You can install this, but your package manager won't pull in any dependencies because a few minor things will work without them. If you
want it to actually do what it was made for, you need to install them yourself." Much bigger problem than the OP's, no?

 

[rusi]

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:

Yes the crux of the matter is what it means 'to work' and therefore
'to not work'

Lets say my car is 'not working'
On further investigation its found that the petrol tank is empty.
A case could be made for either case: 'it (the car) working' or 'its
not working'

To the extent that pragmatically 'not working' is attended by a
mechanic, its not in that category
To the extent that (even more pragmatically) I missed an important
appointment, its in that category

Both of which gloss over the fact that after filling the petrol it may
still not work.
So to conclude: "since I could not check, its vacuously working"
is more problematic than the contrary
"since I could not check, its vacuously not working"

Package systems need to 'federate' so to speak workingness from a
zillion packages to the whole system.
The problem is that workingness is peculiar to each package.
Therefore it seems reasonable to me to ask of a package system that
- it allows a maximum number of different configurations for different
requirements ('without crap')
- it disallows all kinds of misconfigured/non-working systems --
therefore conservative dependencies are good
- the above subject to reasonable best efforts -- so dont cater to
fringe pathological cases (like I want Tkinter but not X)

BTW I suggested earlier that python could have something like KDE (Kde-
full and a smaller Kde-standard).
Just checked that python already has python2.7 and python2.7-minimal
where the description of the latter says: "it can be used in the boot
process for basic tasks"

 

[Steven D'Aprano]

You presumably have a system to test this on. Can you try using ssh -X
to get to it, and then retry that action? It looks like you actually
have everything you need, just no display... which is exactly what you'd
get if you ssh to something that has a real GUI. Not a dependency
problem.

I didn't say it was a dependency problem. I'm just demonstrating that it
is possible for tkinter code to fail even if all the dependencies are
met; and on the other hand, it is useful to be able to import tkinter
even if you cannot display any tkinter windows.

 

[Chris Angelico]

I didn't say it was a dependency problem. I'm just demonstrating that it
is possible for tkinter code to fail even if all the dependencies are
met; and on the other hand, it is useful to be able to import tkinter
even if you cannot display any tkinter windows.

Sure. But I don't know that the situation you're seeing is the same as
the one you'd see if you install tkinter without tk.

ChrisA

 

[Steven D'Aprano]

So you want to go from "this won't work because it's not installed" to
"this won't work, and it there could be a hundred different reasons
why"?

No, that's not what I said. I want to go from:

"this won't work because it's not installed, and I have no idea how to
install it or what dependencies are needed, and even when I meet all the
dependencies and install it, it might still not work"

to:

"this won't work, and here are the reasons why".


Splitting tkinter out into an extra package doesn't buy you much, if
anything. Here is the error I get on Debian when I try importing tkinter:

Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3.1/tkinter/__init__.py", line 42, in <module>
raise ImportError(str(msg) + ', please install the python-tk package')
ImportError: No module named _tkinter, please install the python-tk
package


This implies that the pure Python parts of tkinter are already installed.
It's just the magic _tkinter module which isn't included.

(Also, many points for actually telling me what I need to do to fix the
problem.)

tkinter's main function is to display something on a display. To
say that displaying something is an optional feature is absurd.

Of course it is optional. Python will run on headless systems, or before
X starts up, or on systems where there is no X. Importing tkinter works
before X starts up. There's *no reason why* importing tkinter ought to
fail before X starts up. Obviously you cannot display an X window without
X, well duh, but merely importing tkinter doesn't require an X display.

"You can
install this, but your package manager won't pull in any dependencies
because a few minor things will work without them. If you want it to
actually do what it was made for, you need to install them yourself."
Much bigger problem than the OP's, no?

Not necessarily bigger, just different.

I don't see why "apt-get install python-tk" is considered too trivial to
worry about, but "apt-get install tcl" is considered a "much bigger
problem". So long as the error tells you what to do, they're both more or
less equally hard. Or easy.

We agree on the conditions needed to display tkinter GUI windows:

- you must have Python
- and the tkinter package
- and the _tkinter module
- and Tk/Tcl
- and X

(and an OS, and a computer, and electricity, but we can take them as
given).

We just disagree on where to break the packages up. Debian appears to do
this:

(Python tkinter) (_tkinter) (Tk/Tcl) (X)


Ubuntu appears to do this, I think:

(Python) (tkinter _tkinter) (Tk/Tcl) (X)

I'm suggesting there's no real harm in doing this:

(Python tkinter _tkinter) (Tk/Tcl) (X)


for standard desktop installs, and some minor advantages.

 

[Bob Martin]

I think that if you are worrying about the overhead of the tkinter
bindings for Python, you're guilty of premature optimization. The tkinter
package in Python 3.3 is trivially small, under 2 MB.

"trivially small"?
30 years ago a small mainframe only had 2MB.

 

[Chris Angelico]

"trivially small"?
30 years ago a small mainframe only had 2MB.

30 years ago, people weren't using Tk. We've moved on beyond worrying
about the odd kilobyte of space. (Also, I think you're talking RAM,
and Steven was talking hard disk. Systems can easily have another SI
unit of disk than memory.)

ChrisA

 

[Rui Maciel]

Nobody forces you to do anything. Python is open source, and the source
code is freely available.

That goes both ways, with the added benefit that python-tkinter is already
available in distro's official repositories. If you want to install it, go
for it. Nothing stops you. If you don't then you aren't forced to install
half the packages in the repository just to have a python interpreter in
your system.


Rui Maciel

 

[Rui Maciel]

30 years ago, people weren't using Tk.

And after 30 years gone by, some people still don't use Tk, let alone
Tkinter. There is absolutely no reason to force them to install that if
they don't need to.

We've moved on beyond worrying about the odd kilobyte of space.

That must be reason why you are the only one complaining about that.


Rui Maciel