Python-virtuelle-Umgebungen: venv, Aktivierung und requirements.txt

Das Problem, das virtuelle Umgebungen lösen

Python installieren, pip install requests ausführen, und das Paket landet an einer einzigen globalen Stelle. Für ein Projekt funktioniert das gut. Beim dritten Projekt fängt es an wehzutun:

• Projekt A braucht django==3.2. Projekt B braucht django==5.0. Nur eine Version kann global installiert sein.
• Du willst eine neue Bibliothek testen, aber nicht jedes andere Projekt auf deinem Rechner verschmutzen.
• Eine Kollegin klont dein Repo und hat keine Ahnung, von welchen Paketversionen du eigentlich abhängst.

Eine virtuelle Umgebung ist die Lösung. Ein eigenständiger Ordner mit einem Python-Interpreter und eigenem Bibliotheks-Verzeichnis. Ist sie aktiviert, zeigen python und pip in deinem Terminal in diesen Ordner statt auf das systemweite Python. Pakete, die dort installiert werden, bleiben dort.

Eine mit venv erzeugen

venv liegt Python 3 bei — nichts zu installieren. Aus deinem Projektverzeichnis:

python3 -m venv .venv

Das legt einen Ordner .venv/ neben deinen Code. Der Name .venv ist nahezu universell; der führende Punkt hält ihn aus den meisten Verzeichnislistings fern, und Editoren wie VS Code erkennen ihn automatisch.

Nach dem Befehl enthält der Ordner eine volle Python-Installation (einige zig Megabyte, was normal ist) und ein eigenes pip.

Die Umgebung aktivieren

Die Aktivierung schreibt den PATH deiner Shell um, sodass python und pip auf die im .venv/ zeigen. Der Befehl hängt von der Plattform ab:

# macOS / Linux
source .venv/bin/activate

# Windows (Command Prompt)
.venv\Scripts\activate.bat

# Windows (PowerShell)
.venv\Scripts\Activate.ps1

Dein Prompt bekommt solange ein (.venv)-Präfix, wie die Umgebung aktiv ist — eine sichtbare Erinnerung. Jedes pip install wirkt jetzt nur auf dieses Projekt.

Wenn du für heute fertig bist, stellt deactivate den vorherigen Zustand wieder her:

deactivate

Du musst nicht deaktivieren, bevor du das Terminal schließt — die Shell zu beenden ist dasselbe.

Pakete installieren

Mit aktiver Umgebung installier, was du brauchst:

pip install requests
pip install "pandas>=2.0"
pip install --upgrade requests

Prüf das Installierte mit pip list. Entfern etwas mit pip uninstall requests.

Die installierten Pakete liegen unter .venv/lib/pythonX.Y/site-packages/. Du bearbeitest die nie von Hand — pip verwaltet das Verzeichnis.

Abhängigkeiten mit requirements.txt pinnen

Dein Projekt ist nur dann reproduzierbar, wenn andere dieselben Versionen installieren können. Am einfachsten über requirements.txt:

pip freeze > requirements.txt

pip freeze druckt jedes installierte Paket mit genauer Version. Commite die Datei.

Wenn eine Mitarbeiterin (oder dein zukünftiges Ich auf einem neuen Rechner) das Repo klont:

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Drei Befehle, und ihre Umgebung entspricht deiner.

Ein übliches Projekt-Setup

Der volle Ablauf, von Anfang bis Ende:

# Create the project folder
mkdir my_tool && cd my_tool

# Create and activate the venv
python3 -m venv .venv
source .venv/bin/activate

# Install dependencies
pip install requests rich

# Save them
pip freeze > requirements.txt

# Work on your code...
echo "import requests; print(requests.__version__)" > main.py
python main.py

# When you're done
deactivate

Füge .venv zu deiner .gitignore hinzu

Commite nie den Ordner .venv/. Er ist plattformspezifisch und aus requirements.txt reproduzierbar:

# .gitignore
.venv/
__pycache__/
*.pyc

Ihn zu committen würde das Repo aufblähen, auf anderen Rechnern brechen und OS-spezifische Binärdateien deines Interpreters preisgeben.

Welche Python-Version?

Standardmäßig nutzt python3 -m venv .venv das, was deine Shell als python3 auflöst. Hast du mehrere Python-Versionen (sagen wir 3.12 und 3.13), sei explizit:

python3.13 -m venv .venv

Einmal erzeugt, ist der Interpreter der venv gepinnt — python innerhalb der aktivierten venv nutzt immer diese bestimmte Version, auch wenn dein System-Python wechselt.

Wenn etwas schiefgeht

Ein paar häufige Symptome und Lösungen:

• pip install funktioniert, aber meine Imports scheitern. Du hast gegen das falsche Python installiert. Aktivier die venv vor pip install und prüf noch mal mit which python (macOS/Linux) oder where python (Windows).
• „ModuleNotFoundError“ nach Aktivierung. Die venv wurde ohne bestimmte Bibliotheken erzeugt, oder das Paket ist in einer anderen venv gelandet. pip list zeigt, was tatsächlich drin ist.
• Aktivierungsskript unter Windows nicht gefunden. PowerShell blockiert eventuell unsignierte Skripte. Führ einmal Set-ExecutionPolicy -Scope CurrentUser RemoteSigned aus, um lokale Skripte zuzulassen.
• „No module named venv“. Auf manchen Linux-Distributionen ist venv ein separates Paket. sudo apt install python3-venv unter Debian/Ubuntu.

Jenseits von venv: Poetry, uv, pipenv

Sobald du dich mit venv + pip + requirements.txt wohlfühlst, wirst du Werkzeugen begegnen, die dieselben Ideen mit besserer Ergonomie umschließen:

• Poetry — verwaltet venvs, Abhängigkeiten und Paketierung über eine einzige pyproject.toml.
• uv — ein sehr schneller Drop-in-Ersatz für pip; kümmert sich auch um venvs.
• pipenv — älteres Werkzeug, das das „Pipfile + Pipfile.lock“-Muster bekannt gemacht hat.

Alle sind gut. Keines ist fürs Lernen erforderlich. Mach dich zuerst mit dem schlichten venv-Workflow vertraut; der Rest ist Optimierung.

Was du mitnehmen sollst

• Jedes echte Python-Projekt bekommt seine eigene virtuelle Umgebung.
• Erzeug eine mit python3 -m venv .venv, aktivier sie, dann pip install nach Belieben.
• Pin Abhängigkeiten mit pip freeze > requirements.txt und commite die Datei.
• Commite nie den Ordner .venv/ selbst.
• Verhalten sich Imports seltsam, prüf zuerst, welches Python aktiv ist.

Als Nächstes: das __main__-Muster

Mit eingerichtetem Projekt und installierten Paketen schließt ein letztes Idiom dieses Kapitel ab — der if __name__ == "__main__"-Guard. Er steht in fast jeder Python-Datei, die als Skript laufen soll, und ist Thema der nächsten Seite.