Install packages globally and every project on your machine shares them. That breaks down fast.

Project A needs requests 2.25. Project B needs requests 2.31. Install one and you break the other — there's only one global slot per package. This is dependency hell, and it's why virtual environments exist.

A virtual environment is a private folder holding its own Python and its own packages. Each project gets one, and they can't interfere.

These commands run in your terminal, not in the browser. Read now, run on your own machine.

Creating and activating

python -m venv .venv

That makes a .venv folder in your project. Then activate it:

source .venv/bin/activate

On Windows:

.venv\Scripts\activate

Your prompt gains a (.venv) prefix, showing it's active. Now pip install puts packages in this project only:

pip install requests

When you're done:

deactivate

What activation actually does

It puts the environment's bin folder first on your PATH, so python and pip resolve to the environment's copies instead of the system ones. That's the whole trick — no magic, just lookup order, the same idea as sys.path from lesson 7.1.

You can confirm which one you're using:

which python
python -m pip list

Inside an active environment, pip list shows only that project's packages.

The rules

• One environment per project. Never share.
• Name it .venv. Nearly universal, and editors auto-detect it.
• Never commit it to git. Add .venv/ to .gitignore — it's large, machine-specific, and fully reproducible from requirements.txt (next lesson).
• Activate before installing. Forgetting is the most common mistake; you'll silently install into the global Python.

Checking from inside Python

import sys

print(hasattr(sys, "prefix"))
print(sys.prefix == sys.base_prefix)

sys.prefix is the active Python's location; sys.base_prefix is the underlying system Python. When they differ, you're inside a virtual environment. Equal means you're not.

Alternatives

venv ships with Python and is the right default. You may also meet:

• uv — a very fast modern replacement for venv and pip
• conda — popular in data science, manages non-Python dependencies too
• poetry — manages environments and dependencies together

Learn venv first. The others are variations on the same idea.

Try it yourself

Inspect the environment this lesson is running in.

Checkpoint

• A virtual environment isolates one project's packages from every other project.
• python -m venv .venv creates one; source .venv/bin/activate turns it on.
• Activation just reorders PATH so the local python and pip win.
• One per project, call it .venv, and never commit it.
• sys.prefix != sys.base_prefix tells you one is active.