Python Virtual Environments — warum man ohne nicht arbeiten sollte

Ich weiss, ich weiss. venv einrichten klingt nach Extra-Arbeit. Noch ein Schritt bevor man endlich coden kann. Aber glaub mir — wer einmal sein System-Python zerschossen hat, der richtet danach fuer jedes Projekt eine virtuelle Umgebung ein. Ohne Ausnahme.

Was passiert ohne venv

Python installiert Pakete global. Also wirklich global, fuer den ganzen Rechner. Projekt A braucht Django 4.2, Projekt B laeuft nur mit Django 3.2 — und schon hat man ein Problem. Pip installiert immer die angegebene Version, und die alte fliegt raus. Kein Warnhinweis, kein Backup.

Besonders aergerlich wird es bei Abhaengigkeiten von Abhaengigkeiten. Paket X braucht requests 2.28, Paket Y braucht requests 2.31. Ohne Isolation loest Python das im besten Fall irgendwie, im schlechtesten Fall kracht alles zusammen.

Venv in 30 Sekunden

Ist wirklich nicht kompliziert:

python -m venv .venv
source .venv/bin/activate  # Linux/Mac
.venv\Scripts\activate     # Windows

Danach lebt man in einer Blase. pip install betrifft nur dieses Projekt. Will man raus? deactivate. Fertig. Das wars.

Ein Detail das viele nicht wissen: .venv ist nur eine Konvention beim Namen. Man kann den Ordner nennen wie man will. Aber .venv hat sich durchgesetzt und wird von den meisten Editoren automatisch erkannt. VS Code zum Beispiel findet die Umgebung und schlaegt sie als Interpreter vor.

requirements.txt nicht vergessen

Einmal alles installiert? Dann sichern:

pip freeze > requirements.txt

Und auf einem anderen Rechner oder nach einem Reset:

pip install -r requirements.txt

Das ist der absolute Mindeststandard. Wer im Team arbeitet und keine requirements.txt hat, produziert frueher oder spaeter das klassische bei-mir-gehts-Problem.

Alternativen: Poetry, Pipenv, uv

Gibt es natuerlich auch. Poetry verwaltet Abhaengigkeiten und Paketierung in einem. Pipenv war mal der heisse Tipp, ist inzwischen etwas in den Hintergrund gerueckt. Und uv von Astral — der Newcomer, unfassbar schnell, aber noch jung.

Fuer die meisten Projekte reicht venv voellig aus. Man muss nicht jedes Tool ausprobieren das gerade trendet. Solide Grundlagen schlagen fancy Toolchains.

Typische Stolperfallen

Nummer eins: Die Umgebung aktivieren vergessen. Man installiert froehlich Pakete, wundert sich warum sie im Projekt nicht verfuegbar sind — weil sie global gelandet sind. Die Shell zeigt normalerweise (.venv) am Anfang der Zeile wenn die Umgebung aktiv ist.

Nummer zwei: Den .venv Ordner ins Git-Repository pushen. Der gehoert in die .gitignore. Immer. Der Ordner ist betriebssystemspezifisch und teilweise mehrere hundert MB gross.

Nummer drei: Python-Version im venv. Das venv nutzt die Python-Version mit der es erstellt wurde. Hat man Python 3.11 und 3.12 installiert, muss man beim Erstellen aufpassen welches man nimmt.

Fazit ohne Drumherum

venv ist drei Sekunden Setup und spart stundenlange Fehlersuche. Es gibt keinen vernuenftigen Grund es nicht zu nutzen. Punkt.