Wann und wofür virtuelle Python-Umgebungen?

Python ist wundervoll und hat viele viele viele schöne Libraries. Wenn man sie nicht sowieso schon auf dem Computer installiert hat, kann man sich bei Bedarf ganz viele davon dazu installieren (z.B. mit pip). Unangenehm wird es, wenn man für 2 verschiedene Projekte verschiedene Versionen dieser Libraries braucht. Oder wenn man sein Projekt noch auf mindestens einem anderen Computer betreiben möchte, der vielleicht andere Libraries hat. Sowieso, wenn mehrere Menschen zusammenarbeiten. Auf verschiedenen Betriebsystem-Distributionen (oder gar anderen Betriebssystemen). Oder das Projekt lebt länger … (manche Projekte leben sehr viel länger, als die aktuell laufenden Server).

Die Lösung: Virtuelle Python-Umgebung (kurz VENV).

Jedes Projekt hat seine eigene Umgebung. Damit ist es wunderbar unabhängig von den gerade installierten System-Python-Libraries. Und mit einer requirements.txt ist klar, welche Libraries genau installiert sein müssen.

Unter Python2 gab es den Befehl virtualenv, weil das neue venv etwas anders zu benutzen ist, hab ich hier mal aufgeschrieben, wie das in "modern" geht.

~/project1 $ python3 -m venv VENV --symlinks --prompt PR1

Hier wird die virtuelle Umgebung direkt unter ~/projekt1/VENV angelegt. → Bei der Verwendung von Versionsverwaltung sollte dieses Verzeichnis in die Exclude-Liste aufgenommen werden.

Z.B.

# .gitignore
VENV

Alternativ kann man mit -m venv /pfad/zur/venv-pr1 seine virtuelle Umgebung natürlich auch an anderer Stelle anlegen.

Um die virtuelle Umgebung zu nutzen, muss man seine Shell mit neuen Environment-Variablen "füttern". Deshalb das Script activate nicht aufrufen sondern "sourcen".

~/project1 $ source VENV/bin/activate (bzw. source /pfad/zur/venv-pr1/bin/activate)

(PR1) ~/project1 $ pip install ansible

Um die virtuelle Umgebung klar zu definieren, lässt man aufschreiben, welche Pakete man alle braucht.

(PR1) ~/project1 $ pip list freeze > requirements.txt

Die requirements.txt gehört natürlich auch in die Versionsverwaltung!

Neuer Rechner, VENV mit den richtigen vorgegebenen Paketen bestücken:

(PR1) ~/project1 $ pip install -r requirements.txt

Python-Skript mit VENV im Cronjob aufrufen (immer um "viertel vor der vollen Stunde")

45 * * * * cd /data/home/user1/bin/project1/test-transfer && VENV/bin/python test-transfer.py -n30

python3 venv ist "schon dabei" (ganz nach der Python-Philosophie "Batteries Included" ) UND die offiziell empfohlene Methode (siehe die zwei Links unten), deswegen habe ich das hier beschrieben. Es ist meiner Meinung nach mit den wenigsten Mühen zu installieren und auch auf mehreren Maschinen auszurollen (z.B. als Cron-Job).

Für die alte Methode (wie das schon unter Python2) funktionierte, muss das Tool "virtualenv" installiert sein.

virtualenv --python=python3 --prompt "TEST1|" VENV
source ./VENV/bin/activate

Als Alternative dazu wird gelegentlich pipenv genannt:

• Pipenv: Python Dev Workflow for Humans
• pipenv ist allerdings umstritten: Pipenv: promises a lot, delivers very little

Besonders für Freunde der Linux-Distribution Anaconda und Data-Science könnte als Alternative conda in Frage kommen.

Siehe auch: Python3 Spickzettel

• PEP 405 - What is a virtual environment and why do I need it
• venv - Virtual Environments and pip