Python venv Explained: Create, Activate, and Use It

A virtual environment is a private, isolated copy of Python for one project, its own interpreter, its own installed packages, completely separate from every other project on your machine. This lesson explains why that isolation matters and gives you the exact commands to create, activate, and use one.

By the end, you'll have a venv running in your project folder with the anthropic package installed inside it, not floating around globally.

Key Takeaways

• A venv is a folder holding its own Python interpreter and its own packages, isolated from your system Python
• Without one, two projects needing different versions of the same package will conflict, one always breaks
• python -m venv venv creates it; activating it changes your terminal prompt to show (venv)
• The #1 beginner mistake: running pip install before activating, which installs globally instead of into the project
• venv/ always goes in .gitignore, it's rebuilt from requirements.txt, never committed

What a Virtual Environment Actually Is

Every Python installation on your computer is, by default, one shared, global thing. Every project you write pulls its packages from that same single pool.

A virtual environment breaks that pool apart. Running python -m venv venv creates a folder containing a private copy of the Python interpreter and an empty space for packages, tied to that one project only. Installing a package while that venv is active puts it inside that folder, not into your system-wide Python.

Think of it as giving each project its own toolbox, instead of every project reaching into one shared drawer where tools get moved, replaced, or go missing.

Why You Need One

Here's the conflict a venv prevents. Say Project A needs Django 4.0, and Project B, sitting in a folder right next to it, needs Django 3.2.

With one global Python, only one version of Django can exist at a time. Install 4.0 for Project A, and Project B breaks. Install 3.2 for Project B, and Project A breaks. There's no way to satisfy both from the same shared pool.

Give each project its own venv, and the conflict disappears entirely. Project A's venv holds Django 4.0. Project B's venv holds Django 3.2. Neither knows the other exists.

This isn't a rare edge case, it's the default state of having more than one Python project on your machine. The moment you have two, you need this.

Creating and Activating a venv

python -m venv venv

source venv/bin/activate

venv\Scripts\activate

deactivate

The #1 Beginner Mistake

Forgetting to activate before running pip install is the single most common venv mistake, and it's silent. The command runs, packages appear to install fine, no error at all.

The problem only surfaces later: your script can't find a package that you're certain you installed, because it went into your global Python, not the project's venv.

The fix is always the same: activate first, then install. Order matters here exactly like it did with load_dotenv() in lesson 05.08, the environment has to be set up before the command that depends on it runs.

Your Task

python -m venv venv

pip install anthropic