Python Virtual Environments and pip, Explained

A virtual environment is an isolated Python setup with its own packages, separate from your system Python and your other projects — so two projects that need different versions of a library never clash. Paired with pip (Python’s package installer), it’s how every real Python project manages its dependencies. The rule: always work inside a virtual environment.

It’s a Phase 6 setup skill from the Python roadmap, and skipping it is how beginners end up with a tangled, broken Python install.

The problem it solves

Install packages globally and every project shares one set of versions. Then Project A needs library v1 and Project B needs library v2, and you’re stuck — upgrading for one breaks the other. A virtual environment gives each project its own isolated set of packages, so they never interfere.

Creating and activating one

Python ships with venv. In your project folder:

# Create an environment named "venv"
python -m venv venv

# Activate it
source venv/bin/activate        # macOS / Linux
venv\Scripts\activate           # Windows

# Your prompt now shows (venv) — you're inside it

While it’s active, the Python and pip you run are the environment’s, not the system’s. When you’re done:

deactivate

Installing packages with pip

Inside an active environment, pip installs into that environment only:

pip install requests            # install a package
pip install requests==2.31.0    # a specific version
pip list                        # see what's installed

Because it’s isolated, nothing you install pollutes your system Python or other projects.

Reproducing an environment: requirements.txt

To share or redeploy a project, freeze its dependencies into a file:

pip freeze > requirements.txt          # save exact versions
pip install -r requirements.txt         # recreate them elsewhere

Anyone (including future you) can recreate the exact same setup from that file — the basis of reproducible Python projects.

A typical project start

mkdir my_project && cd my_project
python -m venv venv
source venv/bin/activate
pip install requests
pip freeze > requirements.txt
# ...write code...

This four-line ritual at the start of every project saves enormous pain later.

Common mistakes

• Installing globally (forgetting to activate) — pollutes system Python and causes version conflicts.
• Committing the venv/ folder to git — it’s large and machine-specific; gitignore it and commit requirements.txt.
• Forgetting to activate before running or installing — the classic “it works for me but not in the environment” confusion.
• Not pinning versions — without a requirements.txt, your project isn’t reproducible.

Where this fits

Virtual environments are part of Phase 6 of the Python roadmap — the tooling you adopt once you start real projects — and a practical step in becoming a developer.

The setup ritual and dependency management are covered in Python in One Week and Python in One Month, so you start every project on solid footing.

Create it, activate it, install into it — one environment per project, every time.