Die Isolations-Blase

Du weißt, wie man Pakete mit pip installiert. Alles funktioniert — bis du eines Tages NumPy für ein neues Projekt aktualisierst und dein altes TensorFlow-Projekt sich weigert zu starten. Du hast keine einzige Zeile Code geändert, aber etwas Unsichtbares ist kaputtgegangen.

Willkommen in der Dependency Hell: Der Moment, in dem sich gemeinsam genutzte Paketversionen zwischen Projekten in die Quere kommen. Dieser Artikel stellt zwei Werkzeuge vor, die diesen Albtraum verhindern — Virtual Environments für Python-Level-Isolation und Docker-Container für vollständige System-Isolation.

Dependency Hell — Wenn Pakete kollidieren

Stell dir eine große Werkstatt mit mehreren Werkbänken vor. Werkbank A ist für ein feines Architekturmodell — Präzisionskleber und saubere Oberflächen. Werkbank B ist für die Motorreparatur — Öl, Fett und schwere Werkzeuge. Wenn alle Werkzeuge in ein gemeinsames Regal kommen, kontaminiert das Motoröl irgendwann deine Modellteile. Genau das passiert im globalen site-packages: Ein Projekt aktualisiert NumPy "für sich selbst", aber es betrifft jedes Projekt.

Analogie:

Stell dir eine große Werkstatt mit mehreren Werkbänken vor. Werkbank A ist für ein feines Architekturmodell — Präzisionskleber und saubere Oberflächen. Werkbank B ist für die Motorreparatur — Öl, Fett und schwere Werkzeuge. Wenn alle Werkzeuge in ein gemeinsames Regal kommen, kontaminiert das Motoröl irgendwann deine Modellteile. Genau das passiert im globalen site-packages: Ein Projekt aktualisiert NumPy "für sich selbst", aber es betrifft jedes Projekt.

Definition:

Ein Dependency-Konflikt entsteht, wenn zwei Pakete inkompatible Versionen derselben Bibliothek brauchen, aber Python in einer Umgebung nur eine Version installiert haben kann. Bei globaler Installation teilen sich alle Projekte dasselbe site-packages-Verzeichnis. Ein Update für ein Projekt ändert stillschweigend die Version für alle anderen. In der KI-Entwicklung ist das besonders häufig, weil Frameworks wie TensorFlow und PyTorch Dutzende Abhängigkeiten auf enge Versionsbereiche festpinnen.

In einer echten Werkstatt siehst du das Chaos sofort. In Python verstecken sich Konflikte, bis ein Import zur Laufzeit mit einer kryptischen Fehlermeldung abstürzt. Außerdem kann man in einer Werkstatt theoretisch zwei Versionen des gleichen Werkzeugs nebeneinander haben — in einer Python-Umgebung geht das nicht.

Du versuchst TensorFlow 2.12 und eine neue NumPy-Version zu installieren:

pip install tensorflow==2.12.0 numpy==1.24.2

ERROR: tensorflow 2.12.0 requires numpy<1.24,>=1.22
but you have numpy 1.24.2 which is incompatible.

Noch schlimmer: Projekt A nutzt TensorFlow mit numpy==1.23. Dann installierst du für Projekt B PyTorch mit numpy==2.1. Die globale Installation überschreibt die Version von Projekt A. Beim nächsten Start von Projekt A: Absturz — "module compiled using NumPy 1.x cannot run in NumPy 2.x."

Drei Isolationsstufen

Docker Container Isoliertes OS + Python + Pakete — Vollständige Reproduzierbarkeit

Virtual Environment Isolierte Python-Pakete pro Projekt — Standardlösung für Entwicklung

Global (Chaos) Alle Projekte teilen ein site-packages — Versionskonflikte unvermeidlich

Virtual Environments — Eine Blase pro Projekt

Jede Werkbank bekommt eine unsichtbare Plastikfolie. Alles, was du auf deinen Tisch legst (per pip installierte Pakete), bleibt innerhalb deiner Folie. Der Tisch deines Nachbarn hat seine eigene Folie — kein Öl, kein Kleber, keine verirrten Schrauben. Wenn ein Projekt fertig oder fehlkonfiguriert ist, wirfst du die Folie mitsamt Inhalt weg und fängst frisch an.

Analogie:

Jede Werkbank bekommt eine unsichtbare Plastikfolie. Alles, was du auf deinen Tisch legst (per pip installierte Pakete), bleibt innerhalb deiner Folie. Der Tisch deines Nachbarn hat seine eigene Folie — kein Öl, kein Kleber, keine verirrten Schrauben. Wenn ein Projekt fertig oder fehlkonfiguriert ist, wirfst du die Folie mitsamt Inhalt weg und fängst frisch an.

Definition:

Ein Virtual Environment ist ein Verzeichnisbaum mit einem eigenen Python-Interpreter (oder Symlink), einer Konfigurationsdatei (pyvenv.cfg) und einem eigenen site-packages-Ordner. Nach der Aktivierung zeigt der PATH der Shell auf dieses lokale Verzeichnis statt auf die globale Installation. Seit Python 3.3 ist das venv-Modul Teil der Standard Library — keine zusätzliche Installation nötig.

Die Plastikfolien-Analogie passt gut: Isolation und einfaches Aufräumen. Aber eine venv isoliert nur Python-Pakete — nicht das Betriebssystem, Systembibliotheken oder GPU-Treiber. Und requirements.txt ist präziser als eine Folie — es ist ein exaktes Inventar mit Versionsnummern.

1

python -m venv ki_projekt — Erstellt das Environment-Verzeichnis

2

source ki_projekt/bin/activate (Linux/macOS) oder ki_projekt\Scripts\activate (Windows) — Aktiviert es (Prompt ändert sich zu (ki_projekt))

3

pip install transformers — Installiert nur in dieser Umgebung

4

pip freeze > requirements.txt — Speichert exakte Versionen

5

deactivate — Kehrt zum globalen Python zurück

pip freeze gibt eine exakte Liste aller installierten Pakete mit Versionsnummern aus:

pip freeze > requirements.txt

# Inhalt von requirements.txt:
transformers==4.37.0
tokenizers==0.15.0
numpy==1.26.3
...

Ein anderer Entwickler kann mit pip install -r requirements.txt exakt die gleiche Umgebung auf seinem Rechner aufbauen. So funktioniert Reproduzierbarkeit in Python-Projekten.

Ohne aktives Virtual Environment installiert pip global — jedes Paket landet im gemeinsamen site-packages und betrifft alle Projekte. Prüfe vor jedem pip install, ob dein Prompt (ki_projekt) zeigt. Im Zweifel: which python (Unix) oder where python (Windows) — der Pfad sollte auf dein venv-Verzeichnis zeigen.

Interaktiv: Vorher vs. Nachher

Schalte zwischen den beiden Szenarien um: Links siehst du, wie eine globale Installation zum Versionskonflikt führt. Rechts zeigt der gleiche Ablauf mit Virtual Environments — jedes Projekt hat seine eigene Blase, kein Paket stört das andere. Achte besonders auf die Fehlermeldung links und den sauberen Trainingsstart rechts.

 Globale Installation (Chaos) 
Terminal
$ pip install tensorflow==2.12.0 
Successfully installed numpy-1.23.5 tensorflow-2.12.0
   
# 3 Monate später: neues Projekt
$ pip install pytorch numpy==2.1.0 
Successfully installed numpy-2.1.0 pytorch-2.3.0
   
# Zurück zum alten Projekt...
$ python train.py 
ModuleNotFoundError: module compiled using NumPy 1.x
cannot run in NumPy 2.x
ERROR: tensorflow 2.12.0 requires numpy<1.24
 Beide Projekte teilen ein globales site-packages. Das Update für Projekt B zerstört Projekt A. 

Ohne venv: Gemeinsames Chaos

site-packages (global)

numpy 2.1.0tensorflow 2.12.0pytorch 2.3.0

Projekt A
braucht numpy<1.24

Projekt B
braucht numpy>=2.0

Docker — Der Frachtcontainer für Code

Bevor es standardisierte Frachtcontainer gab, mussten Hafenarbeiter Säcke, Kisten und Fässer einzeln verladen — jedes anders geformt. Heute geht alles in einen genormten Stahlcontainer. Dem Schiff ist egal, ob Autos, Getreide oder Maschinen drin sind — es transportiert einfach Container. Docker funktioniert genauso: Der Entwickler packt das gesamte Setup (OS, Python, Bibliotheken, Code) in einen Container, und der Server startet und stoppt einfach Container.

Analogie:

Bevor es standardisierte Frachtcontainer gab, mussten Hafenarbeiter Säcke, Kisten und Fässer einzeln verladen — jedes anders geformt. Heute geht alles in einen genormten Stahlcontainer. Dem Schiff ist egal, ob Autos, Getreide oder Maschinen drin sind — es transportiert einfach Container. Docker funktioniert genauso: Der Entwickler packt das gesamte Setup (OS, Python, Bibliotheken, Code) in einen Container, und der Server startet und stoppt einfach Container.

Definition:

Docker ist ein Container-System, das nicht nur Python-Pakete, sondern die gesamte Laufzeitumgebung isoliert: Basis-Betriebssystem, Systembibliotheken, Werkzeuge und Anwendungscode. Ein Docker Image ist eine unveränderliche Vorlage (ein Stapel von Schichten) mit einem Dateisystem-Snapshot. Ein Docker Container ist eine laufende Instanz eines Images. Ein Dockerfile ist eine Textdatei mit Build-Anweisungen (FROM, RUN, COPY, CMD). Container teilen sich den Kernel des Hosts, isolieren aber Prozesse, Dateisysteme und Netzwerke.

Ein Frachtcontainer hat eigene physische Wände; Docker-Container teilen sich den Kernel des Hosts — sie sind leichter, aber auch abhängiger. Einen physischen Container zu klonen braucht Zeit; Docker-Images werden in Sekunden kopiert und in Registries gepusht. Und Frachtcontainer starten nicht "in Sekunden" — Docker-Container schon, weil kein Bootvorgang nötig ist.

Virtual Environment (venv)

Isoliert nur Python-Pakete. Leichtgewichtig, eingebaut ab Python 3.3, kein Extra-Tool nötig. Ideal für alltägliche Entwicklung. Das Betriebssystem und Systembibliotheken werden nicht isoliert.

Docker Container

Isoliert das gesamte System: OS, Bibliotheken, GPU-Treiber, Python und Pakete. Schwerer, braucht Docker-Installation. Ideal für Deployment, Zusammenarbeit und spezifische GPU/CUDA-Setups.

FROM python:3.11
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "train.py"]

Zwei Befehle zum Bauen und Ausführen — läuft identisch auf jeder Maschine mit Docker:

docker build -t my_ai_project .
docker run --rm my_ai_project

Docker-Container teilen sich den Kernel des Host-Systems — sie booten kein eigenes Betriebssystem. Deshalb starten sie in Sekunden statt Minuten. Sie sind viel leichter als VMs. Und Docker ersetzt venv nicht: In der Praxis werden beide oft kombiniert — Docker für die OS-Ebene, venv für die Python-Ebene innerhalb des Containers.

Es gibt einen wichtigen Unterschied zwischen gepinnten und ungepinnten Versionen:

# Gepinnt (reproduzierbar):
numpy==1.24.4
transformers==4.37.0

# Ungepinnt (nicht reproduzierbar!):
numpy
transformers

Ungepinnt bedeutet: "Installiere die neueste Version." Was heute die neueste ist, ist morgen eine andere. pip freeze erfasst alle Versionen exakt, inklusive transitiver Abhängigkeiten. Für saubere Dateien kannst du alternativ nur die Top-Level-Pakete manuell pflegen — aber immer mit Version.

In der KI-Produktion sind Container der Standard. Warum? Weil CUDA/cuDNN-Versionen exakt stimmen müssen — Container lösen das.

Hugging Face bietet Docker Spaces zum Deployen beliebiger Frameworks. AWS SageMaker liefert vorgefertigte Container für TensorFlow und PyTorch, unterstützt aber auch eigene. GPU-beschleunigte Container mit NVIDIA CUDA sind der einzige zuverlässige Weg, Deep-Learning-Setups reproduzierbar zu machen.

Wenn du in späteren Artikeln KI-Modelle baust und deployst, wird Docker dein ständiger Begleiter sein.

Dependency Hell entsteht, wenn zwei Projekte unterschiedliche Versionen desselben Pakets brauchen, aber eine globale Python-Installation teilen. Die Lösung: Jedem Projekt seine eigene Umgebung geben.
python -m venv projektname erstellt eine isolierte Python-Umgebung. source projektname/bin/activate (Linux/macOS) oder projektname\Scripts\activate (Windows) wechselt hinein.
pip freeze > requirements.txt speichert exakte Paketversionen. pip install -r requirements.txt reproduziert die Umgebung auf einem anderen Rechner. Immer Versionen pinnen.
Ein Virtual Environment isoliert nur Python-Pakete. Docker isoliert das gesamte System: OS, Bibliotheken, GPU-Treiber, Python und Pakete — alles in einem portablen Container.
Verwende venv für die tägliche Entwicklung. Verwende Docker, wenn du vollständige Reproduzierbarkeit über Maschinen hinweg brauchst, auf Server deployst oder spezifische GPU/CUDA-Setups benötigst.

Was ist die "Dependency Hell"?

Wenn nicht genug Speicherplatz für Pakete vorhanden ist

Wenn zwei Projekte verschiedene Versionen desselben Pakets brauchen und sich eine globale Installation teilen

Wenn pip ein Paket auf PyPI nicht finden kann

Wenn Python nicht richtig installiert ist

1. Was ist die "Dependency Hell"?

☐ A) Wenn nicht genug Speicherplatz für Pakete vorhanden ist
☐ B) Wenn zwei Projekte verschiedene Versionen desselben Pakets brauchen und sich eine globale Installation teilen
☐ C) Wenn pip ein Paket auf PyPI nicht finden kann
☐ D) Wenn Python nicht richtig installiert ist

2. Welche Befehle erstellen und aktivieren ein Virtual Environment?

☐ A) pip install venv && activate
☐ B) python -m venv mein_projekt && source mein_projekt/bin/activate
☐ C) docker build -t mein_projekt .
☐ D) python --create-env mein_projekt

3. Dein Kollege soll exakt die gleichen Paketversionen nutzen. Was gibst du weiter?

☐ A) Den gesamten venv-Ordner
☐ B) Einen Screenshot von pip list
☐ C) Eine mit pip freeze erstellte requirements.txt
☐ D) Das globale site-packages-Verzeichnis

4. Wann sollte man Docker statt nur eines Virtual Environments verwenden?

☐ A) Immer, weil Docker in jeder Hinsicht besser ist
☐ B) Wenn man nicht nur Python-Pakete, sondern auch OS, Systembibliotheken oder GPU-Treiber isolieren muss
☐ C) Nur wenn man in Java programmiert
☐ D) Wenn das Projekt weniger als drei Pakete hat

Auflösung: 1) B · 2) B · 3) C · 4) B

Checkpoint

Was passiert, wenn zwei Projekte unterschiedliche Versionen derselben Bibliothek brauchen und beide global installiert sind, ohne Virtual Environment?
Was macht der Befehl python -m venv mein_projekt mit deiner Python-Installation und Paketverwaltung?
Was ist der Hauptunterschied zwischen einem Python Virtual Environment und einem Docker Container in Bezug auf das, was sie isolieren?

Die Isolations-Blase

Dependency Hell — Wenn Pakete kollidieren

Dependency-Konflikt

Analogie:

Definition:

Beispiel: TensorFlow vs. NumPy

Drei Isolationsstufen

Virtual Environments — Eine Blase pro Projekt

Virtual Environment (venv)

Analogie:

Definition:

Der venv-Workflow in 5 Schritten

Reproduzierbarkeit mit requirements.txt

Warnung: Niemals pip install ohne aktives venv

Interaktiv: Vorher vs. Nachher

Docker — Der Frachtcontainer für Code

Docker

Analogie:

Definition:

Beispiel: Minimales Dockerfile für ein KI-Projekt

Irrtum: Docker ist eine Virtuelle Maschine

Deep Dive: requirements.txt richtig machen

Deep Dive: Docker im KI-Ökosystem

Das Wichtigste auf einen Blick

Quiz: Virtual Environments & Docker

Was ist die "Dependency Hell"?

Checkpoint

Dependency Hell — Wenn Pakete kollidieren

Dependency-Konflikt

Analogie:

Definition:

Beispiel: TensorFlow vs. NumPy

Drei Isolationsstufen

Virtual Environments — Eine Blase pro Projekt

Virtual Environment (venv)

Analogie:

Definition:

Der venv-Workflow in 5 Schritten

Reproduzierbarkeit mit requirements.txt

Warnung: Niemals pip install ohne aktives venv

Interaktiv: Vorher vs. Nachher

Docker — Der Frachtcontainer für Code

Docker

Analogie:

Definition:

Beispiel: Minimales Dockerfile für ein KI-Projekt

Irrtum: Docker ist eine Virtuelle Maschine

Deep Dive: requirements.txt richtig machen

Deep Dive: Docker im KI-Ökosystem

Das Wichtigste auf einen Blick

Quiz: Virtual Environments & Docker

Was ist die "Dependency Hell"?

Checkpoint

Verwandte Inhalte

Artikel

Externe Code-Bibliotheken (Packages)

Versionskontrolle mit Git

Wie ein Computer "denkt" - Hardware-Basics

Das Terminal

Glossar

Timeline