Why Every Python Project Needs a Virtual Environment

Python Project Essentials — Part 1

If you’ve just finished learning Python and you’re about to build your first real project, there’s one thing you’ll run into almost immediately — before you write a single line of “real” code: the virtual environment.

It sounds like a small, boring setup step. It isn’t. It’s one of those quiet fundamentals that separates someone who knows Python syntax from someone who knows how to build Python projects — and skipping it is one of the most common ways beginners (and honestly, even some experienced developers) break their own projects without realizing why.

This is the first post in a new series, Python Project Essentials, where I’m covering the basic-but-critical things nobody really sits you down and explains: virtual environments, requirements.txt, .env and .env.example, pyproject.toml, project structure, and more. None of these topics are technically "deep," but they matter a lot — especially now, in the era of AI-assisted ("vibe") coding, where it's easier than ever to generate code without pausing to think about how a project should actually be managed.

Let’s start at the beginning.

The Problem: Everything Installs Globally by Default

Here’s a scenario. You’ve installed Python on your system — let’s say Python 3.12 — and that installation is what we call your global Python interpreter.

Now imagine you’re working on two projects at once:

• Project A needs pandas version 1.2
• Project B needs pandas version 1.8

Both projects need the same package, just different versions. If you don’t do anything special, and you just run:

pip install pandas

pip installs pandas globally — directly into your system’s Python installation. Whatever version happens to be the latest available (let’s say 3.5) gets installed globally. Now neither Project A nor Project B has the version it actually needs. Project A might throw errors or break, and so might Project B — because both are silently depending on a global installation that doesn't match what either of them was built for.

This is the core problem: a single global Python environment cannot serve multiple projects with conflicting dependency needs.

The Solution: Isolated Environments

To solve this, we create separate, isolated spaces on our system — one per project. These isolated spaces are exactly what we call virtual environments.

Think of it simply: a virtual environment is just an isolated folder. Inside that folder, you get:

• Your own Python interpreter (a copy, isolated from the global one)
• Your own space to install packages, completely separate from other projects

So instead of both Project A and Project B fighting over the same global pandas installation, you create two separate virtual environments — say venv1 for Project A and venv2 for Project B — and install the specific version each project needs, inside its own environment.

Get Prajjwal Sule’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Project A gets pandas 1.2 in venv1. Project B gets pandas 1.8 in venv2. No conflicts. No breakage. Each project lives in its own clean, self-contained world.

Common Mistakes (Even Experienced Developers Make These)

Before jumping into the practical implementation, here are three mistakes that come up constantly — and not just among beginners. I’ve seen developers with 3–4 years of experience slip up on these too:

1. Creating a virtual environment but forgetting to activate it. If you don’t activate it before installing packages, everything still goes into your global environment — the virtual environment sitting there does nothing for you.
2. Pushing the virtual environment folder to GitHub. The venv folder contains thousands of files (interpreter binaries, installed packages, etc.). It should never be committed to version control — that’s what .gitignore is for, which we'll cover in an upcoming part of this series.
3. Using a single global virtual environment for every project. This defeats the entire purpose. If Project A, B, and C are all sharing one virtual environment, you’re back to square one — no isolation, no separation of dependencies.

Let’s Implement It

Enough theory — let’s actually create and use a virtual environment.

Step 1: Create a Project Folder

mkdir episode-one-virtual-environment
cd episode-one-virtual-environment

Step 2: Create the Virtual Environment

On Linux/Mac:

python3 -m venv .venv

On Windows:

python -m venv .venv

Once this runs, you’ll see a new folder called .venv appear in your directory. Inside it, you'll find subfolders like bin (or Scripts on Windows), include, and lib — this is your isolated environment. Anything you install from here on will live inside this folder, not in your global Python installation.

Step 3: Activate It

This is the step people forget — and if you skip it, installing packages still goes to your global environment.

source .venv/bin/activate

Windows (Command Prompt):

.venv\Scripts\activate

Windows (PowerShell):

.venv\Scripts\Activate.ps1

Once activated, you’ll notice your terminal prompt changes — it now shows (.venv) at the start of the line. That's your confirmation: you're now working inside the isolated environment, not the global one.

Step 4: Install Packages Inside the Environment

pip install pillow
pip list

Step 5: Deactivate When You’re Done

deactivate

That’s it. One command, and you’re back outside the virtual environment. Your global Python setup remains untouched by whatever you installed inside .venv.

A Quick Note on Naming

You’ll notice most developers name their virtual environment folder .venv or venv. This isn't a hard rule — it's just convention. You could name it anything, even something like ml-with-prajjwal, and it would work exactly the same way. The dot-prefix (.venv) is just a common professional convention, and it also makes it easy to add a single, predictable line to your .gitignore later.

That said — stick to the convention. It’s what most tooling, tutorials, and teammates will expect, and consistency here saves confusion down the line.

Breaking Down the Command

Let’s quickly decode what python -m venv .venv actually means, piece by piece:

• python3 (or python) — run Python
• -m — run a module
• venv — the specific module we're running: Python's built-in virtual environment module
• .venv — the name of the directory where the isolated environment will be created

In plain terms: “Python, use your virtual environment module to create an isolated directory here.”

Wrapping Up

This might seem like a small, almost trivial step in your Python journey — and technically, it is. There’s no deep algorithmic complexity here. But the consequences of skipping it are real: broken projects, dependency conflicts, and hours of confused debugging that could’ve been avoided with one command and one habit.

This is exactly the kind of foundational knowledge that tends to get skipped when you’re learning Python through scattered tutorials — you learn the language, but not how to actually manage a project built with it.

In the next part of Python Project Essentials, we’ll cover requirements.txt — how to capture and share your project's exact dependencies so anyone else (or future you) can reproduce your exact setup in seconds.

If you found this useful, the video version of this post (with the full walkthrough, in Hindi) is on my YouTube channel, MLwithPrajjwal. More parts in this series are coming soon.