Python: Create a 'Virtual Environment' in 10 Seconds

Why Every Python Project Needs Its Own Environment

Install two projects that need different versions of the same package globally, and eventually one of them breaks. Python's built-in venv module solves this by creating an isolated directory with its own Python interpreter and its own site-packages folder, completely separate from your system Python and from every other project's environment. It ships with Python 3.3+ — no separate install required.

Creating the Environment

Navigate to your project folder and run:

cd my-project
python3 -m venv venv

On Windows, the command is usually just python instead of python3:

python -m venv venv

This creates a folder named venv containing a self-contained copy of the Python interpreter along with pip. The second argument (venv) is just the directory name — it can be anything, though venv or .venv are the near-universal conventions, and most editors' Python extensions auto-detect one of those two names.

Activating the Environment

Creating the environment does not put you inside it — you have to activate it, and the command differs by platform and shell:

# macOS / Linux (bash or zsh)
source venv/bin/activate

# Windows PowerShell
venv\Scripts\Activate.ps1

:: Windows Command Prompt
venv\Scripts\activate.bat

Once activated, your terminal prompt changes to show the environment name in parentheses, typically (venv), confirming that python and pip now point at the isolated copies inside the venv folder rather than your system installation. Confirm it worked with:

which python
# or on Windows: where python

The path returned should point inside your project's venv directory, not a system path like /usr/bin/python3.

Installing Packages Inside the Environment

With the environment active, any package you install with pip goes into the isolated venv folder, not your system-wide Python:

pip install requests flask

These packages are invisible to any other project or to your system Python outside this activated shell — exactly the isolation you want.

Freezing and Restoring Dependencies

Once your project's dependencies are installed, capture the exact versions into a requirements.txt file:

pip freeze > requirements.txt

This produces a plain text file listing every installed package and its pinned version:

flask==3.0.3
requests==2.32.3
Werkzeug==3.0.3

Commit this file to your repository. Anyone cloning the project — or you, on a different machine — can recreate the exact same dependency set with:

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Deactivating When You're Done

To leave the virtual environment and return to your system Python, simply run:

deactivate

This works identically across macOS, Linux, and Windows since it is a shell function that venv defines during activation, not a separate script.

Keeping venv Out of Git

Never commit the venv folder itself — it is large, platform-specific, and entirely reproducible from requirements.txt. Add it to .gitignore:

venv/
.venv/
__pycache__/
*.pyc

One Environment Per Project

The convention worth adopting: create a fresh venv the moment you start a new Python project, before installing a single package. It costs a few seconds and completely eliminates the class of bug where "it works on my machine" turns out to mean "it works with whatever random package versions happen to be installed globally on my machine." If you juggle many projects and want automatic activation/deactivation when you cd in and out of directories, tools like pyenv-virtualenv or direnv build on top of the same underlying concept.