Virtual Environments & Requirements Files

Learn to create and use Python virtual environments with venv and conda, and manage dependencies with requirements.txt.

Introduction

A virtual environment is an isolated, self-contained copy of Python that keeps one project's packages separate from every other project's. Without it, every package you install lands in a single global Python installation shared by everything on your machine — a setup that breaks down the moment two projects need different versions of the same library.

This lesson covers the two most common ways to create isolated environments: Python's built-in venv module, and conda environments.

What You Will Learn

Why isolating dependencies per project matters.
How to create and activate a virtual environment with python -m venv.
How to freeze and restore dependencies with pip freeze and requirements.txt.
How conda environments work as an alternative.

Why Isolate Dependencies Per Project

Imagine Project A was built against pandas 1.5 and relies on behavior that changed in later releases, while Project B needs pandas 2.1 for a feature that was only added recently. If both projects share one global Python installation, only one version of pandas can be installed at a time — upgrading for Project B silently breaks Project A.

A Real Conflict

Without isolation, running "pip install pandas==2.1" for Project B can quietly downgrade or upgrade the pandas version that Project A depends on, causing it to fail the next time it runs — often with no obvious error pointing back to the real cause.

A virtual environment sidesteps this entirely: each project gets its own private copy of installed packages, so upgrading one project's dependencies never touches another's.

Creating a Virtual Environment with venv

venv is built into Python — no extra installation is required. Run it inside your project folder to create a new isolated environment.

python -m venv .venv

This creates a .venv folder containing its own copy of the Python interpreter and an empty site-packages directory, ready to receive project-specific installs.

Activating and Using the Environment

Creating the environment does not put you inside it — you need to activate it first. The activation command differs slightly by operating system.

macOS / Linux

source .venv/bin/activate

Windows (PowerShell)

.venv\Scripts\Activate.ps1

Once activated, your terminal prompt changes to show the environment name, and any "pip install" command from that point on installs only into .venv, not system-wide.

Terminal Prompt

Click Run to see what this code prints.

Freezing and Restoring Dependencies

Once you have installed the packages a project needs, pip freeze exports the exact versions currently installed into a requirements.txt file.

pip freeze > requirements.txt

requirements.txt

Click Run to see what this code prints.

Anyone else — a teammate, a CI server, or future you on a new machine — can then recreate the exact same environment with a single command.

pip install -r requirements.txt

Conda Environments

conda bundles environment management directly into the same tool used for installing packages, and it can also pin the Python version itself.

conda create -n myenv python=3.11

conda activate myenv

conda env export > environment.yml

venv vs conda Environments

Aspect	venv	conda env
Built into Python	Yes	No — requires Anaconda/Miniconda
Can pin the Python version	No — uses whatever interpreter created it	Yes
Handles binary/GPU dependencies	No	Yes
Manifest file	requirements.txt (via pip freeze)	environment.yml (via conda env export)
Typical use case	General Python and web projects	Data science and ML projects with heavy dependencies

Common Mistakes

Avoid These Mistakes

Installing packages before activating the environment, which puts them in the global Python install instead.
Committing the .venv folder itself to version control instead of just requirements.txt — it is large, machine-specific, and unnecessary to share.
Forgetting to regenerate requirements.txt after installing new packages, leaving teammates with an outdated dependency list.

Best Practices

Create a fresh virtual environment for every new project — never reuse one environment across unrelated projects.
Add .venv/ to your .gitignore file so it never gets committed by accident.
Regenerate requirements.txt right after installing or upgrading any package, not just at the end of a project.

Frequently Asked Questions

Do I need venv if I already use conda?

No — they solve the same isolation problem in different ways. Use one or the other for a given project, not both at once.

How do I leave a virtual environment?

Run "deactivate" in the terminal — it works the same way for both venv and conda environments.

Can I delete a virtual environment safely?

Yes — simply delete the .venv folder (or run "conda env remove -n myenv" for conda). As long as requirements.txt or environment.yml exists, it can be recreated at any time.

Key Takeaways

Virtual environments isolate a project's dependencies from every other project on the machine.
python -m venv creates an environment; source .venv/bin/activate or .venv\Scripts\Activate.ps1 activates it.
pip freeze > requirements.txt captures exact versions; pip install -r requirements.txt restores them.
conda create -n myenv python=3.11 offers the same isolation with built-in Python version pinning and binary dependency support.

Summary

Isolating dependencies per project is one of the simplest habits that prevents an entire category of "it works on my machine" bugs. Whether you use venv or conda, the goal is the same: every project gets its own clean, reproducible set of installed packages.

Lesson 4 Completed

You can create and activate a virtual environment.
You can freeze and restore dependencies with requirements.txt.
You know how conda environments compare to venv.

Next Lesson →