Warum und wie verwenden Sie virtuelle Umgebungen?

Question

Accepted Answer

Eine **virtuelle Umgebung** ist eine isolierte Python-Umgebung mit eigenen installierten Paketen, getrennt von der System-Python und von anderen Projekten. Sie löst **Abhängigkeitskonflikte** — verschiedene Projekte können verschiedene (sogar inkompatible) Versionen desselben Pakets verwenden.

## Das Problem, das sie löst

```text
Project A needs Django 3.2
Project B needs Django 4.2
→ Installing globally, they CONFLICT — you can't have both versions system-wide.
Virtual environments give each project its OWN isolated set of packages.
```

Ohne Isolation führt die globale Installation von Paketen zu Versionskonflikten zwischen Projekten und kann Systemwerkzeuge beschädigen, die auf bestimmte Versionen angewiesen sind.

## Eine erstellen und verwenden (integriertes venv)

```bash
# 1. create a virtual environment (a folder named .venv)
python -m venv .venv

# 2. ACTIVATE it (shell-specific)
source .venv/bin/activate      # macOS/Linux
.venv\Scripts\activate         # Windows

# 3. now pip installs go INTO this env, isolated from the system
pip install django requests

# 4. when done
deactivate
```

Nach der Aktivierung beziehen sich `python` und `pip` auf die isolierten Kopien der Umgebung — Pakete werden nur dort installiert, nicht systemweit.

## Abhängigkeiten erfassen und reproduzieren

```bash
pip freeze > requirements.txt       # record exact installed versions
pip install -r requirements.txt     # recreate the env elsewhere (teammate, CI, prod)
```

Eine `requirements.txt` macht die Umgebung **reproduzierbar** — jeder kann die exakt gleichen Abhängigkeiten nachbilden und vermeidet damit "läuft auf meinem Computer"-Probleme.

## Moderne Werkzeuge

```text
venv + pip      → built-in, standard, widely used
poetry          → dependency management + lockfile + packaging (popular)
pipenv          → combines pip + venv with a lockfile
uv / pdm        → newer, faster tools
conda           → common in data science (manages Python versions + non-Python deps too)
```

Neuere Werkzeuge (poetry, uv) ergänzen Sperrdateien und bessere Abhängigkeitsauflösung, aber das Kernkonzept — isolierte Pro-Projekt-Umgebungen — ist dasselbe.

## Schließen Sie die env immer aus der Versionskontrolle aus

```text
# .gitignore
.venv/        ← don't commit the environment; commit requirements.txt/lockfile instead
```

## Warum es wichtig ist

Virtuelle Umgebungen sind essenzielle, Standard-Praxis für jedes Python-Projekt — sie verhindern Abhängigkeitskonflikte zwischen Projekten und zwischen Projekten und der System-Python, und (mit `requirements.txt`/Sperrdateien) machen Umgebungen über Maschinen, Teamkollegen, CI und Produktion hinweg reproduzierbar.

Sie zu überspringen führt zu Versionskonflikten, beschädigten Systemwerkzeugen und nicht reproduzierbaren Setups.

Das Verständnis, wie man Umgebungen erstellt, aktiviert und Abhängigkeiten erfasst — und die moderne Werkzeuglandschaft (poetry, uv) — ist grundlegend für professionelle Python-Entwicklung und eine grundlegende Erwartung in jedem echten Projekt.