Can tkinter be installed on a per-Python-installation basis?

Python Help
1

This question is related to a documentation issue I opened on the Github tracker, which I filed mainly as a hack because I didn’t see the Discourse link initially.

To sum up: some Python installations do not include Tkinter, even though it is described in the documentation as something that should just be present automatically. There are a variety of reasons for this.

I know that there are OS-specific ways to install Tkinter into the “system Python” for Unix-like systems, and to update (“repair”) or replace Python installations (from the binary installer) on Windows to include Tkinter. Of course, if I add another, non-virtual installation of Python to my Linux system (say, in order to have an up-to-date version, while the system continues to rely on 3.8 for essential scripts that were tested on 3.8), I can choose to include Tkinter or not at installation time (especially if I am compiling from source). However, I would like to be able to change my mind later, and add Tkinter to a Python that doesn’t already have it.

I also know that a virtual environment created from a “base” that includes Tkinter, will have Tkinter; and one created from a base that does not, will not. I would like to be able to fix this later, and add Tkinter to virtual environments created from my system Python, without having to use the s-word (sudo) and modify that Python.

I also know that there are not official PyPI packages to install Tkinter as if it were a third-party library, and furthermore that PyPI hosts many, deceptively named packages that look like they might resolve the issue, or at least help, but will not. (Notably, turtle, which does not make it possible to use the turtle standard library - but is instead an old, unmaintained, 2.x-only package for throttling HTTP requests.)

Is there any endorsed way to resolve this, and add Tkinter to an arbitrary Python installation that doesn’t already have it? Is there any good reason not to host a package on PyPI to accomplish this, or why it wouldn’t be possible? How about providing, say, some kind of bootstrap script, analogous to ensurepip? Just how much trouble would I be getting myself into, if I tried to hack something (say, by trying to compile my own DLL/.so for _python, and manually copying that and the appropriate .py files into the right places)?

2

I guess you are using a debian or ubuntu system that splits out parts of python.
I had to learn on debian that I needed to install the debian packages for pip, venv etc so that the batteries where included again.
In your case you need to do pip, venv and tkinter it seems.

On Windows when installing TkInter is installed by default and some one choose not to include it. As you observer, running the python installer again will fix that.

Not sure why the above know solutions are not sufficient.

After fixing your python installation remake your venv.
For any non-trivia venv I always have a script to do that.

3

I’m using Ubuntu-based Mint, but I’m not simply asking to solve a personal problem (though I would apply the advice to my own situation). Actually I’m trying to research a full, platform-agnostic explanation of the overall topic, so I can make a canonical Q&A on Stack Overflow.

I don’t need pip or venv packages - venv is a standard library module that I can run just fine with python -m, and I don’t want to install anything in my system Python - that’s the point. Virtual environments created with venv will automatically bootstrap pip so there’s no problem - I can install packages there.

What I’m trying to do is make virtual environments that contain Tkinter even though the system Python still does not. My sense is that Tkinter is not so special, that I shouldn’t be able to treat it the same way as any third-party library. Plenty of those include compiled code.

4

At least on debian using the system python venv does not work until you install python3-venv(?) package. Are you saying that is not the case with mint?

Why are you against installing os provided and supported packages of python.org code?

5

I clarified on the issue of python versus tcl/tk installs on the 3 major systems. None of our installers lack tcl/tk and they all install tcl/tk unless the user says otherwise and will install tcl/tk later if requested. This is the endorsed way to get tkinter for python x.y.z for windows and mac.

If you do not like what a *nix distribution does, talk to the distribution managers, not python coredev. Tkinter is part of the python tarball. They split the tarball how they want before adding chunks to their package manager.

As I said before, address your pypi concerns to the packaging category. But tkinter is not a 3rd party library and should not be on pypi.

6

I don’t recall installing it. It shows up in Synaptic as removable, but my oldest dpkg logs all suggest it’s only been upgraded. So they might be preloading python3-venv (you did get the package name correct.

Only very weakly against it, but on principle. If the vendor excluded it, shouldn’t I conclude there was a good reason for that? If installations can either exclude or include it, then why shouldn’t I be given the ability to add or remove it per-installation at will?

I’m not sure if I’ve been understood. I don’t object to what my distribution is doing. I’m trying to respect the decision, by leaving the system Python alone and having the optional(?) content only in the virtual environment. Isn’t being able to do that, one of the main purposes of virtual environments?

But if it isn’t possible/supported, then simply knowing that is valuable. I can go ahead and install it without worrying that I overlooked an option, and I can write a Stack Overflow canonical (and/or a blog article) that confidently denies the option.

7

I think you missunderstand that debian is doing.

They do not install all of the core python by default. It is up to you to add in the parts they broke out.
This is not debian says you cannot have venv, pip, tk etc, it is them saying “we think its not needed by default”.

On fedora, for example, they do not do this. You get venv, pip and tk in the default install of python.

8

No, I understood that perfectly.

What I am asking about, is adding in those parts to a virtual environment (or other non-core installation), even though they are not added to the core Python. More generally, adding them to a specifically chosen installation that does not already have them (as opposed to installing system packages that are hard-coded to modify system components). The goal is to specifically avoid doing anything to the default install, based on a trust that the vendor made that choice for a reason. I don’t know how many more ways there are to say this. My creativity is wearing thin.

9

You seem to be arguing that unless your os installs something when you first put the os on your computer you should not add packages. I add os provided packages after initial install all the time. Why are parts of python core special and should not be installed?

10

@kknechtel

As far as I know there is no pip installable version of tkinter, so that tkinter could be added in a virtual environment for a Python that does not already have tkinter. My assumption is that a Python without tkinter is considered a broken Python. So there is no reason for anyone to build a pip installable distribution of tkinter. If a Python installation does not have tkinter then it is broken, and it needs to be fixed. On Debian/Ubuntu, I assume it can be fixed by apt installing the missing part. In other cases, Python might need to be re-installed from scratch.

My understanding of Debian/Ubuntu, is that the “default” installation of Python is not really meant for usage by the user. It is installed because Debian/Ubuntu itself depends on Python, and so it installs some kind of intentionally chopped down version of Python as to not take too much disk space. This “default” Python installation is not really meant to be usable by the user. If the user wants to use Python then they have to intentionally trigger the full Python installation (sudo apt-get install ...). So basically, a Python without tkinter is a broken Python that needs to be fixed to be usable.

Maybe it is feasible to build a pip installable distribution of tkinter. If you start building it, maybe you will find like-minded contributors.