How to manage Python virtual environments

Working with Python long enough means you have definitely hit that moment where a project needs one version of a library, but another project screams bloody murder if you try to install the same thing. That is exactly why virtual environments exist, and at PythonSkillset, we have helped hundreds of developers avoid the messy cleanup that comes from ignoring this basic tool. Let me walk you through how to manage them properly, without the fluff.

Why bother with virtual environments at all?

Think of a virtual environment as a clean sandbox. You can install whatever packages you want inside it, and nothing leaks out to the rest of your system. If you break something in the sandbox, you just delete it and start fresh. Your system Python installation stays untouched, and your other projects keep working.

Without virtual environments, you end up with what I call "dependency hell." One day you update a package globally for a new project, and suddenly an older project from six months ago breaks because it relied on an older version. That is not a fun debugging session.

Starting a new environment

The built-in venv module is all you need. It ships with Python 3.3 and later, so there is nothing extra to install.

Open your terminal, navigate to your project folder, and run:

python -m venv my_env

Replace my_env with whatever name makes sense for your project. Many developers use venv or .venv as a convention, and it is a good habit.

Once created, you need to activate it. On Windows:

my_env\Scripts\activate

On macOS or Linux:

source my_env/bin/activate

Your terminal prompt will change to show the environment name. That is your cue that you are now working inside the sandbox.

Installing packages safely

With the environment active, install whatever packages your project needs using pip:

pip install requests pandas

Everything stays inside that environment. Your system Python remains untouched, and other projects do not get affected.

Freezing dependencies (the smart way)

Once you have your packages working, freeze the list into a requirements file:

pip freeze > requirements.txt

This file becomes your project's dependency manifest. When someone else clones your project, they can recreate the exact same environment by running:

pip install -r requirements.txt

A small tip from our experience at PythonSkillset: always commit this file to version control. It saves hours of troubleshooting later.

Managing multiple environments easily

If you juggle many projects, managing separate folders for environments can get tedious. That is where tools like virtualenvwrapper (Linux/macOS) or virtualenvwrapper-win (Windows) help. They centralize all your environments in one directory and let you switch between them with simple commands.

Install it globally:

pip install virtualenvwrapper

Then set up your environment directory in your shell config file:

export WORKON_HOME=~/Envs
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
source /usr/local/bin/virtualenvwrapper.sh

Now you can create and switch environments with:

mkproject my_new_project
workon my_new_project

It keeps your project root clean and your environments organized.

Deleting environments when you are done

Environments take up disk space, and unused ones pile up. When a project is finished, simply delete the environment folder:

rm -rf my_env

Or if using virtualenvwrapper:

rmvirtualenv my_env

No leftover cruft. No registry entries to clean. Just gone.

Common mistakes to avoid

Never commit the actual environment folder to version control. It contains machine-specific paths and binary files that do not belong in a shared repository. Add it to your .gitignore file:

my_env/
env/
.venv/

Also, do not install packages globally unless you absolutely have to. Tools like pipx are better for installing CLI tools that you want available everywhere without polluting your system Python.

When you need more power

For larger projects or teams, consider pipenv or poetry. These tools combine dependency management with virtual environment creation, and they handle lock files that pin exact versions for reproducibility.

But for most projects, plain venv with requirements.txt is perfectly fine. It is simple, built-in, and understood by every Python developer.

At PythonSkillset, we have seen too many developers skip this step and regret it later. Take the five extra minutes to set up a virtual environment. Your future self, who will not have to debug a broken import at three in the morning, will thank you.