Hey,
ohne die CustomTkinter Python-Bibliothek zu kennen: Grundsätzlich kann man Pakete auch ohne Virtuelle Umgebung (venv) installieren. Allerdings ist das nicht ratsam, weil die dann global auf dem System installiert werden - das führt schnell zu Chaos und Konflikten. Ist daher schon der richtige Weg, das zu nutzen. Ich habe zu dem Thema mal einen ausführlicheren Beitrag gemacht, der das alles inklusive Verwendung erklärt.

Um das automatische Starten einer virtuellen Umgebung zu simulieren, habe ich ein kleines Demo-Skript genommen, das prüft, ob es in einer virtuellen Umgebung läuft:
Code:
$ cat demo.py 
import sys

def in_venv():
    return sys.prefix != sys.base_prefix

print("In virtualenv: " + str(in_venv()))

$ python demo.py
In virtualenv: False

$ virtualenv .
created virtual environment CPython3.9.2.final.0-64 in 644ms

$ source bin/activate
(python-virtualenv-demo) $ python demo.py
In virtualenv: True
Um die Python Demo-Anwendung in der virtuellen Umgebung zu starten, würde ich ebenfalls ein Shell-Skript anlegen (das ist bei so was eine sinnvolle Idee, das zusätzlich vorher die Umgebung lädt:
Code:
#!/bin/bash
source $(pwd)/bin/activate
python demo.py
Code:
$ chmod +x start-venv.sh
$ ./start-venv.sh
In virtualenv: True
Dies kann dann wiederum in der XDG .autostart Datei gestartet werden, sodass die schlank bleibt. Und man ggf. zu Testzwecken den gleichen Weg einfacher gehen kann. Ich führe stderr & stdout in einer Bash-Shell zusammen und schreibe sie in eine Datei, damit man die Ausgabe, ob das Skript in einer virtuellen Umgebung läuft, nach dem Neustart sehen kann:
Code:
$ cat ~/.config/autostart/python.desktop
[Desktop Entry]
Type=Application
Name=Python venv demo
Exec=bash -c "/home/u-labs/python-virtualenv-demo/start-venv.sh >> /home/u-labs/python-virtualenv-demo/autostart.log 2>&1"
Demo:
Code:
$ sudo reboot
$ ssh pi
$ cat python-virtualenv-demo/autostart.log
In virtualenv: True