Request python3-tkinter and tk to round out the python3 stdlib install in bluefin

[klmcwhirter]

Describe the package

I'd like to request the packages python3-tkinter and tk because those were separated out from python3 a few years ago.

Although tkinter is in the Python stdlib, Fedora created a separate package for it years ago.

This makes sense because of the additional indirect dependency it carries of tk. But for those of us that use that stdlib package it adds additional burden to track updates from Fedora without it.

I am currently working around it by installing those in a distrobox. But that means I have to also install the python3 package there as well and the export it back to the host in my ~/.local/bin dir.

This creates unwanted duplication both in disk space and update procedure.

Note that the python3-pip package is added by bluefin in the "all" section of packages.json. But it may be appropriate to add these to the "dx" section (since I am using the bluefin-dx-nvidia image). But these really should be in "all".

Thanks for considering my request.

Image

All Images

[m2Giles]

python3-pip was added due to being our install method for topgrade. This is something we may look at in the future.

What do the additional dependencies look like if adding tk?

We do want to keep the development packages to a minimum since we recommend containerized development patterns.

[klmcwhirter]

What do the additional dependencies look like if adding tk?

Just python3-tkinter and tk are needed.

I am not exactly sure what you are looking for ... but here is the output from dnf info python3-tkinter tk:

Installed packages
Name            : python3-tkinter
Epoch           : 0
Version         : 3.13.1
Release         : 2.fc41
Architecture    : x86_64
Installed size  : 2.0 MiB
Source          : python3.13-3.13.1-2.fc41.src.rpm
From repository : updates
Summary         : A GUI toolkit for Python
URL             : https://www.python.org/
License         : Python-2.0.1
Description     : The Tkinter (Tk interface) library is a graphical user interface toolkit for
                : the Python programming language.
Vendor          : Fedora Project

Name            : tk
Epoch           : 1
Version         : 8.6.14
Release         : 2.fc41
Architecture    : x86_64
Installed size  : 3.6 MiB
Source          : tk-8.6.14-2.fc41.src.rpm
From repository : fedora
Summary         : The graphical toolkit for the Tcl scripting language
URL             : http://tcl.sourceforge.net
License         : TCL AND HPND-Pbmplus AND CC-BY-SA-3.0 AND MIT-open-group AND MIT
Description     : When paired with the Tcl scripting language, Tk provides a fast and powerful
                : way to create cross-platform GUI applications.
Vendor          : Fedora Project

We do want to keep the development packages to a minimum since we recommend containerized development patterns.

I do appreciate that. And I share your goals. But the python stdlib is incomplete as documented at docs.python.org without these.

The end result for some of my projects, python might as well not even be in the image at all. I started to layer these into my install, but stopped myself.

The challenge is that the python versions between the image and my distrobox get out of sync. It seems silly to save 5MiB.

And so I thought I would ask.

The other thing I am vehemently trying to avoid is a custom image for such a small thing. I have come to the conclusion that there must be a much larger reason to warrant a custom image.

Thanks again.

[EDIT]

Oh and I guess I should mention that this is to run apps. One of them is a budget package I wrote to take CSV files from my bank, perform automatic categorization and report on the results in various ways.

I am using containers for development. I have for years. That is why bluefin-dx is such a good fit for me.

Please see these posts I contributed as I am learning more about working with the tools in bluefin:

• Bluefin - use docker distrobox containers in vscode
• Bluefin - use podman distrobox containers in vscode

[klmcwhirter]

@m2Giles ,

After thinking about it some more, here is what I see while trying to install those in a fresh container. This might be a clearer view.

$ sudo dnf install python3-tkinter tk
Updating and loading repositories:
Repositories loaded.
Package                                                          Arch           Version                                                          Repository                               Size
Installing:
 python3-tkinter                                                 x86_64         3.13.1-2.fc41                                                    updates                               2.0 MiB
Installing dependencies:
 tcl                                                             x86_64         1:8.6.14-2.fc41                                                  fedora                                4.2 MiB
 tk                                                              x86_64         1:8.6.14-2.fc41                                                  fedora                                3.6 MiB

Transaction Summary:
 Installing:         3 packages

Total size of inbound packages is 3 MiB. Need to download 3 MiB.
After this operation, 10 MiB extra will be used (install 10 MiB, remove 0 B).

Hope that helps.

[klmcwhirter]

Oh, you have me thinking ...

How can I tell which packages being installed are sacred; only should be used for system maintenance? Or in the case of "dx" - to enable development where the package needs to be close to the metal?

I guess the answer is - all of them.

If a new-to-linux user installs a flatpak app, the dependencies are expected to come with it. And there lies the friction. There are no "python" runtime flatpak modules. Only desktop environments.

So it seems that this container-first concept has a ways to go yet.

I am looking for ways to avoid 50 installs of python on my hard disk, while still having the freedom to "try" new versions of things easily by spinning up a container that is configured slightly differently for the test. I have been doing that for years with docker-compose as a build tool.

The first time I wondered what it would take to upgrade the mysql version in a wordpress website and realized all I had to do was change a number in a docker-compose.yml file and try it ... I was sold!

We simply are not at a point where the flatpak runtime concept has that sort of utility yet. I think I see it.

BTW, I love the Podman Desktop! It supports podman and docker in ways I have only seen with the k8s web portal or OpenShift portal before. kudos to j0rge for the suggestion.

The purpose of bluefin is to get us all used to thinking of the host image as off-limits and do everything else in containers - period. I should ignore what is installed by the image - as a detail of a black box.

I am learning.

I'll think about the strategy I need some more.

One of the policies I am developing for myself is to use podman for system stuff, and docker for development stuff. That way I am always free to do docker system prune -af --volumes without breaking my system assumptions. I guess I will need to do that more frequently to eliminate python installs in devcontainers. They are easily reproducible.

But I think I have reached the conclusion that this is an undesirable request. There just cannot be much demand for TCL/Tk at this point.

Thanks for the free lesson ;)

Closing this issue as not needed.