Waarom en hoe gebruik je virtuele omgevingen?

Question

Accepted Answer

A **virtual environment** is een geïsoleerde Python-omgeving met eigen geïnstalleerde pakketten, gescheiden van de systeem-Python en andere projecten. Het lost **dependency conflicts** op — verschillende projecten kunnen verschillende (zelfs inkompatibele) versies van hetzelfde pakket gebruiken.

## Het probleem dat het oplost

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

Zonder isolatie leidt globale pakketinstallatie tot versieverwarring tussen projecten en kan systeemtools breken die afhangen van specifieke versies.

## Eentje aanmaken en gebruiken (ingebouwde 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
```

Eenmaal geactiveerd, verwijzen `python` en `pip` naar geïsoleerde kopieën van de omgeving — pakketten worden alleen daar geïnstalleerd, niet systeemwijd.

## Afhankelijkheden vastleggen en reproduceren

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

Een `requirements.txt` maakt de omgeving **reproducible** — iedereen kan dezelfde afhankelijkheden recreëren, wat voorkomt dat problemen zoals "het werkt op mijn computer" ontstaan.

## Modern gereedschap

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

Nieuwere tools (poetry, uv) voegen lockfiles en betere afhankelijkheidsoplossing toe, maar het kernidee — geïsoleerde per-project-omgevingen — is hetzelfde.

## Sluit de env altijd uit van versiebeheer

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

## Waarom het belangrijk is

Virtuele omgevingen zijn essentieel, standaardpraktijk voor elk Python-project — ze voorkomen afhankelijkheidconflicten tussen projecten en tussen projecten en de systeem-Python, en (met `requirements.txt`/lockfiles) maken omgevingen reproduceerbaar over machines, teamgenoten, CI en productie.

Ze overslaan leidt tot versieverwarring, kapotte systeemtools en irreproduceerbare setups.

Begrijpen hoe je omgevingen aanmaakt, activeert en afhankelijkheden vastlegt — en het moderne toollandschap (poetry, uv) — is fundamenteel voor professionele Python-ontwikkeling en een basisverwachting in elk echt project.