Pourquoi et comment utilisez-vous les environnements virtuels?

Question

Accepted Answer

Un **environnement virtuel** est un environnement Python isolé avec ses propres paquets installés, distinct de Python système et d'autres projets. Il résout les **conflits de dépendances** — différents projets peuvent utiliser différentes versions (même incompatibles) d'un même paquet.

## Le problème qu'il résout

```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.
```

Sans isolation, installer des paquets globalement entraîne des conflits de version entre les projets et peut casser les outils système qui dépendent de versions spécifiques.

## Créer et utiliser un (venv intégré)

```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
```

Une fois activé, `python` et `pip` se réfèrent aux copies isolées de l'environnement — les paquets s'installent uniquement là, pas à l'échelle du système.

## Capturer et reproduire les dépendances

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

Un `requirements.txt` rend l'environnement **reproductible** — quiconque peut recréer les mêmes dépendances exactes, évitant les problèmes "ça marche sur ma machine".

## Outils modernes

```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)
```

Les outils plus récents (poetry, uv) ajoutent des fichiers de verrouillage et une meilleure résolution des dépendances, mais le concept fondamental — environnements isolés par projet — est le même.

## Excluez toujours l'env du contrôle de version

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

## Pourquoi c'est important

Les environnements virtuels sont essentiels, une pratique standard pour tout projet Python — ils empêchent les conflits de dépendances entre les projets et entre les projets et Python système, et (avec `requirements.txt`/fichiers de verrouillage) rendent les environnements reproductibles sur les machines, les coéquipiers, la CI et la production.

Les ignorer entraîne des conflits de version, des outils système cassés et des configurations non reproductibles.

Comprendre comment créer, activer et capturer les dépendances — et le paysage des outils modernes (poetry, uv) — est fondamental pour le développement Python professionnel et une attente élémentaire dans tout vrai projet.