Miért és hogyan használsz virtuális környezeteket?

Question

Accepted Answer

A **virtuális környezet** egy izolált Python-környezet a saját telepített csomagjaikkal, elkülönítve a rendszer Pythontól és más projektektől. Megoldja a **függőségi konfliktusokat** — a különböző projektek az ugyanazon csomag különböző (még inkompatibilis) verzióit használhatják.

## A megoldott probléma

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

Izolálás nélkül a csomagok globális telepítése verzióütközésekhez vezet a projektek között, és megtörheti azokat a rendszert, amelyek adott verziókra támaszkodnak.

## Létrehozás és használat (beépített 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
```

Az aktiválás után a `python` és `pip` a környezet izolált másolatai — a csomagok csak ott települnek, nem rendszerszinten.

## Függőségek rögzítése és reprodukálása

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

Egy `requirements.txt` **reprodukálhatóvá** teszi a környezetet — bárki pontosan ugyanezeket a függőségeket újra létrehozhatja, megelőzve a "működik a gépemen" problémákat.

## Modern eszközök

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

Az újabb eszközök (poetry, uv) lezáró fájlokat és jobb függőségi feloldást adnak, de az alapvető koncepció — projekt szerinti izolált környezetek — ugyanaz.

## Mindig zárja ki az env-t a verziókontrollból

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

## Miért számít

A virtuális környezetek alapvetőek, standard gyakorlat bármely Python-projekthez — megakadályozzák a függőségi konfliktusokat a projektek között és a projektek és a rendszer Pythona között, és (`requirements.txt`/lezáró fájlokkal) reprodukálhatóvá teszik a környezeteket a gépek, csapattagok, CI és termelés között.

Annak mellőzése verzióütközésekhez, megtört rendszert eszközökhöz és nem reprodukálható beállításokhoz vezet.

Az a megértése, hogy hogyan kell virtuális környezeteket létrehozni, aktiválni és függőségeket rögzíteni — valamint a modern eszközök táját (poetry, uv) — alapvetően fontos a professzionális Python-fejlesztéshez, és alapvető elvárás bármely valódi projektben.