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

**URL:** <https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089>\
**Category:** Python Help\
**Created:** [March 23, 2023, 3:07am UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089 "2023-03-23T03:07:28Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![kknechtel](https://avatars.discourse-cdn.com/v4/letter/k/e47c2d/32.png) [@kknechtel](https://discuss.python.org/u/kknechtel)\
**Post date:** [March 23, 2023, 3:07am UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089/1 "2023-03-23T03:07:28Z")

</div>

This question is related to a [documentation issue I opened on the Github tracker](https://github.com/python/cpython/issues/102501), 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)?

---

<div class="post-metadata">

**Author:** ![barry-scott](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@barry-scott](https://discuss.python.org/u/barry-scott)\
**Post date:** [March 23, 2023, 8:44am UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089/2 "2023-03-23T08:44:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kknechtel](https://avatars.discourse-cdn.com/v4/letter/k/e47c2d/32.png) [@kknechtel](https://discuss.python.org/u/kknechtel)\
**Post date:** [March 23, 2023, 11:51pm UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089/3 "2023-03-23T23:51:59Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![barry-scott](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@barry-scott](https://discuss.python.org/u/barry-scott)\
**Post date:** [March 24, 2023, 12:01am UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089/4 "2023-03-24T00:01:25Z")

</div>

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](http://python.org) code?

---

<div class="post-metadata">

**Author:** ![tjreedy](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tjreedy/32/137_2.png) [@tjreedy](https://discuss.python.org/u/tjreedy)\
**Post date:** [March 24, 2023, 12:03am UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089/5 "2023-03-24T00:03:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kknechtel](https://avatars.discourse-cdn.com/v4/letter/k/e47c2d/32.png) [@kknechtel](https://discuss.python.org/u/kknechtel)\
**Post date:** [March 24, 2023, 12:26am UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089/6 "2023-03-24T00:26:06Z")

</div>

> [@barry-scott](#):
>
> 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?

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.

> [@barry-scott](#):
>
> Why are you against installing os provided and supported packages of [python.org](http://python.org) code?

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?

> [@tjreedy](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![barry-scott](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@barry-scott](https://discuss.python.org/u/barry-scott)\
**Post date:** [March 24, 2023, 10:22am UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089/7 "2023-03-24T10:22:18Z")

</div>

> [@kknechtel](#):
>
> 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(?)

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.

---

<div class="post-metadata">

**Author:** ![kknechtel](https://avatars.discourse-cdn.com/v4/letter/k/e47c2d/32.png) [@kknechtel](https://discuss.python.org/u/kknechtel)\
**Post date:** [March 24, 2023, 9:47pm UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089/8 "2023-03-24T21:47:05Z")

</div>

> [@barry-scott](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![barry-scott](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@barry-scott](https://discuss.python.org/u/barry-scott)\
**Post date:** [March 24, 2023, 10:28pm UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089/9 "2023-03-24T22:28:00Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![sinoroc](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/sinoroc/32/1607_2.png) [@sinoroc](https://discuss.python.org/u/sinoroc)\
**Post date:** [March 25, 2023, 10:26am UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089/10 "2023-03-25T10:26:30Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![claudioperez](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/claudioperez/32/28995_2.png) [@claudioperez](https://discuss.python.org/u/claudioperez)\
**Post date:** [July 4, 2025, 9:49pm UTC](https://discuss.python.org/t/can-tkinter-be-installed-on-a-per-python-installation-basis/25089/11 "2025-07-04T21:49:13Z")

</div>

I was facing exactly this issue. I ended up just taking the `_tkinter.c` file from cpython, and packaging it as a standalone module which I now maintain on PyPI under the name [_tcinter_](https://pypi.org/project/tcinter). I’m a bit behind some of the upstream changes though. It would be nice to have an easier or more standard solution.
