Why and how do you use virtual environments?

Question

Accepted Answer

A **virtual environment** is an isolated Python environment with its own installed packages, separate from the system Python and from other projects. It solves **dependency conflicts** — different projects can use different (even incompatible) versions of the same package.

## The problem it solves

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

Without isolation, installing packages globally leads to version clashes between projects and can break system tools that depend on specific versions.

## Creating and using one (built-in 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
```

Once activated, `python` and `pip` refer to the environment's isolated copies — packages install only there, not system-wide.

## Capturing and reproducing dependencies

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

A `requirements.txt` makes the environment **reproducible** — anyone can recreate the exact same dependencies, preventing "works on my machine" issues.

## Modern tooling

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

Newer tools (poetry, uv) add lockfiles and better dependency resolution, but the core concept — isolated per-project environments — is the same.

## Always exclude the env from version control

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

## Why it matters

Virtual environments are essential, standard practice for any Python project — they prevent dependency conflicts between projects and between projects and the system Python, and (with `requirements.txt`/lockfiles) make environments reproducible across machines, teammates, CI, and production.

Skipping them leads to version clashes, broken system tools, and irreproducible setups.

Understanding how to create, activate, and capture dependencies — and the modern tooling landscape (poetry, uv) — is fundamental to professional Python development and a basic expectation in any real project.