Python Virtual Environments: venv Beginner Guide

In this lesson

A virtual environment (or venv) gives each Python project its own private set of packages, so different projects never clash when they need different versions. Creating one per project is a habit worth forming early — this lesson shows you how to make, activate, and leave a venv.

Explain it like I’m 5

A virtual environment is a separate toolbox for each project. Project A’s tools stay in A’s box and Project B’s in B’s, so upgrading one never breaks the other.

The problem it solves

Without isolation, every package installs into one shared global Python. Then Project A needs version 1 of a library while Project B needs version 2 — and they can’t both win. A virtual environment (‘venv’) gives each project its own isolated packages, so their requirements never conflict.

Creating a venv

From your project folder, run python3 -m venv .venv. This creates a .venv folder containing a private copy of Python and a place for that project’s packages. You make one venv per project; the .venv name is a common convention.

Activating it

Creating isn’t enough — you must activate it so your shell uses it. On macOS/Linux: source .venv/bin/activate. On Windows: .venv\Scripts\activate. Once active, your prompt usually shows (.venv), and pip install now installs into this project only.

Example

# Run these in a terminal, in your project folder.
python3 -m venv .venv
source .venv/bin/activate
# your prompt now shows (.venv)
python -m pip install requests
deactivate

Output

(.venv) $   # packages now install into this project only

Create, activate, install, and leave a venv. (Run locally.)

Deactivating, and not committing it

Run deactivate to leave the environment and return to the global Python. Because a venv is large and machine-specific, you don’t share it — instead you record your packages in a requirements.txt file (next lesson) and add .venv/ to .gitignore so it’s never committed.

What’s inside a venv, and the tools around it

A venv isn’t magic — it’s just a folder. Inside .venv there’s a bin/ (or Scripts/ on Windows) holding a Python and a pip, and a lib/ where this project’s packages get installed. Activating simply puts that bin/ first on your PATH, so plain python and pip point at the project’s copies.

The built-in python -m venv is the standard tool. You may also hear of virtualenv (a faster third-party version) and conda (popular in data science) — all solve the same isolation problem. You record what’s installed with pip and a requirements.txt.

Example

.venv/
    bin/         # activate script, python, pip   (Scripts/ on Windows)
    lib/         # this project's installed packages
    pyvenv.cfg   # records which base Python it was built from

Inside a .venv folder. (Layout simplified.)

Common mistake: Installing packages without activating the venv

Why it happens:

If you forget to activate, pip install goes to the global Python, defeating the isolation and risking version clashes.

How to fix it:

Check for the (.venv) prefix in your prompt before installing. If it’s missing, activate the environment first.

Common mistake: Committing the .venv folder to version control

Why it happens:

The folder is large and tied to your machine and OS, so it bloats the repo and won’t work for others.

How to fix it:

Add .venv/ to .gitignore and share a requirements.txt so others can recreate the environment.

What problem does a virtual environment solve?

After creating a venv, what must you do before installing into it?

Mini exercise (easy)

Write the exact terminal commands to: create a venv called .venv, activate it on macOS/Linux, and confirm which Python is now in use.

These are terminal commands you’d type in a real shell — we can’t run them in the browser, but you can assemble them here so the checker can confirm them. Fill in the three command strings.

create = "..."     # create a venv called .venv
activate = "..."   # activate it on macOS/Linux
confirm = "..."    # confirm which python is now in use
print(create)
print(activate)
print(confirm)

create = "python -m venv .venv"
activate = "source .venv/bin/activate"
confirm = "which python"
print(create)
print(activate)
print(confirm)

What to learn next

You learned what a virtual environment is, why isolating each project’s dependencies matters, how to create and activate a venv, how it changes your shell prompt, and how to deactivate it. You assembled the exact commands to create a venv, activate it, and confirm which Python was in use.

With a clean environment ready, you can safely pull in code the community has shared. Installing Packages with pip covers pip and PyPI, installing and pinning versions, and using requirements.txt for reproducible setups. When you’re ready, continue to the next lesson.