How to Create a Virtual Environment in Python

You finish building your first Python project, everything works perfectly, and then a few weeks later you start a second project that needs a different version of the same library. You upgrade the library for the new project and suddenly the first project breaks. You downgrade it to fix the first project and now the second one stops working. You spend an afternoon going back and forth between two projects, changing the same library version, and fixing the same errors over and over again.

This is the exact problem Python virtual environments were built to solve. A virtual environment is an isolated Python installation that belongs to one project and one project only. It has its own copy of Python, its own set of installed packages, and its own package versions completely separate from every other project on your machine. You can have one project running pandas 1.5 and another running pandas 2.1 and neither one knows or cares what the other is doing.

Every professional Python developer uses virtual environments. Every Python tutorial eventually assumes you are using one. This guide shows you exactly how to create them, use them, and manage them step by step across Windows, Mac, and Linux.

What Is a Python Virtual Environment?

A virtual environment is a self-contained directory that holds a specific Python interpreter and a specific collection of installed packages. When the environment is activated, any Python command or pip install you run operates entirely within that environment without touching your system-wide Python installation or any other project’s environment.

Think of it like a separate apartment for each of your Python projects. Your system Python is the apartment building. Each virtual environment is an individual unit with its own kitchen, its own furniture, and its own rules. What happens in one apartment does not affect any other. You can furnish one apartment with pandas 1.5 and another with pandas 2.1 and they coexist peacefully in the same building without interfering with each other.

Without virtual environments all your projects share the same global Python installation. Every package you install goes into the same place and every project sees every other project’s packages whether it needs them or not. Version conflicts become inevitable the moment two projects need different versions of the same library.

Setting Up: What You Need Before Starting

Python 3.3 and above ships with the venv module built in. No additional installation is required. Verify your Python version before proceeding:

python --version

or on some systems:

python3 --version

If the output shows Python 3.3 or higher you have everything you need. If Python is not installed, download it from python.org and follow the installer for your operating system. On Windows make sure you check the option to add Python to your PATH during installation.

Step by Step: Creating and Using a Virtual Environment

Step 1: Navigate to Your Project Folder

Always create the virtual environment inside your project folder. Open your terminal or command prompt and navigate to where your project lives:

cd path/to/your/project

If the project folder does not exist yet, create it first:

mkdir my_project
cd my_project

Starting from the project folder keeps everything organized. The virtual environment directory sits alongside your project files rather than floating somewhere unrelated on your system.

Step 2: Create the Virtual Environment

Run this command to create the virtual environment. The name venv at the end is the name of the directory that will be created to hold the environment. You can name it anything but venv and .venv are the standard conventions that most developers and tools recognize:

python -m venv venv

On Mac or Linux if your system defaults to Python 2 for the python command, use python3 instead:

python3 -m venv venv

After running this command you will see a new folder called venv appear in your project directory. Inside it Python has created a complete isolated environment with its own Python interpreter, its own pip, and its own site-packages directory where installed packages will live.

Your project folder structure now looks like this:

my_project/
    venv/
        bin/          (Mac/Linux)
        Scripts/      (Windows)
        lib/
        include/
        pyvenv.cfg

Step 3: Activate the Virtual Environment

Creating the environment does not automatically switch you into it. You need to activate it. The activation command differs by operating system:

On Windows:

venv\Scripts\activate

On Mac and Linux:

source venv/bin/activate

After activating, your terminal prompt changes to show the environment name in parentheses at the beginning of the line:

(venv) your-computer:my_project username$

That prefix is your confirmation that the environment is active. Every Python and pip command you run from this point operates inside the virtual environment, completely isolated from your system Python and all other environments.

Step 4: Install Packages Inside the Environment

With the environment active, install packages using pip exactly as you normally would. The packages install into the virtual environment, not into your global Python installation:

pip install pandas numpy matplotlib scikit-learn

Verify that packages installed correctly and check their versions:

pip list

You will see only the packages installed in this specific environment, not any packages from other projects or your global Python installation. This is the isolation working exactly as intended.

Step 5: Confirm Which Python You Are Using

This is a useful sanity check, especially when switching between multiple projects. Verify that the active Python is the one inside your virtual environment:

On Mac and Linux:

which python

On Windows:

where python

The output should point to the Python interpreter inside your venv folder, something like /home/user/my_project/venv/bin/python rather than /usr/bin/python. If it points to the global Python, the environment is not activated correctly.

Step 6: Save Your Dependencies to a Requirements File

Once your project has all the packages it needs, save them to a requirements.txt file. This file is what allows anyone else, or your future self on a different machine, to recreate the exact same environment from scratch:

pip freeze > requirements.txt

The requirements.txt file lists every installed package and its exact version:

numpy==1.26.2
pandas==2.1.4
matplotlib==3.8.2
scikit-learn==1.3.2

Commit this file to your version control repository alongside your code. It is as important as the code itself for reproducibility.

Step 7: Recreate the Environment From requirements.txt

When someone else clones your project or you set it up on a new machine, they create a fresh virtual environment and install everything from the requirements file in one command:

python -m venv venv
source venv/bin/activate      (Mac/Linux)
venv\Scripts\activate         (Windows)
pip install -r requirements.txt

Three commands and the environment is identical to the original. Every package at the exact same version. This is the entire workflow that makes Python projects portable and reproducible across different machines and different developers.

Step 8: Deactivate the Environment

When you are done working on the project, deactivate the environment to return your terminal to the global Python context. The deactivate command is the same on all operating systems:

deactivate

The prefix disappears from your prompt confirming you are back to the global Python environment. Activating and deactivating environments as you switch between projects is the normal daily workflow for Python developers who work on multiple projects.

Working With Multiple Projects

The real power of virtual environments becomes clear when you have multiple projects running simultaneously. Each project gets its own environment created independently, activated when you work on that project, and deactivated when you switch to something else:

project_a/
    venv/           (pandas 1.5, numpy 1.23)
    main.py
    requirements.txt

project_b/
    venv/           (pandas 2.1, numpy 1.26)
    main.py
    requirements.txt

When you switch from project_a to project_b the workflow is:

deactivate
cd ../project_b
source venv/bin/activate

Two commands and you are in a completely different package environment. No version conflicts. No interference between projects.

venv vs virtualenv: What Is the Difference?

Feature	venv	virtualenv
Built into Python	Yes, Python 3.3 and above	No, requires pip install
Speed	Slightly slower to create	Faster environment creation
Python version support	Python 3 only	Python 2 and Python 3
Additional features	Basic	More configuration options
Recommended for beginners	Yes	Not necessary

venv is the right choice for the vast majority of Python developers today. It is built in, requires no installation, and covers every use case that beginners and intermediate developers encounter. virtualenv is worth knowing about but you do not need it unless you are working with Python 2 legacy code or need features that venv specifically lacks.

Common Limitations

The environment is tied to a specific Python version. When you create a virtual environment it uses whichever Python version ran the venv command. If you later upgrade Python on your system, the virtual environment still uses the old version. For a Python upgrade, create a fresh environment using the new Python version and reinstall your packages from requirements.txt.

Virtual environments do not follow you when you move the project folder. The environment contains absolute paths baked in during creation. If you move or rename the project folder the environment breaks and needs to be recreated. This is why virtual environments should never be committed to version control and why recreating from requirements.txt is always the correct approach when moving a project.

System level packages are not available by default. By default a virtual environment has no access to packages installed in the global Python installation. This is intentional isolation. If you need access to a specific system package inside the environment, use the –system-site-packages flag when creating it: python -m venv venv –system-site-packages. Use this sparingly as it weakens the isolation the environment provides.

Common Mistakes to Avoid

Committing the venv folder to version control. The venv directory is large, machine-specific, and completely unnecessary in version control because it can always be recreated from requirements.txt. Add venv to your .gitignore file. The requirements.txt file is what belongs in version control, not the environment itself.

Installing packages without the environment activated. If you run pip install while the environment is not active, the package installs into your global Python, not your project environment. Always check for the environment name prefix in your terminal prompt before running pip install. If the prefix is not there, activate the environment first.

Forgetting to update requirements.txt after installing new packages. If you install a new package mid-project but do not run pip freeze again to update the requirements file, the next person who recreates the environment will be missing that package and get an import error. Make updating requirements.txt part of your workflow every time you install something new.

Using one virtual environment for multiple projects. A virtual environment is meant to serve one project. Sharing an environment between projects defeats the purpose because you are back to the same version conflict problems virtual environments were built to solve. One project, one environment, always.

Virtual Environment Cheat Sheet

Task	Command
Create environment	python -m venv venv
Activate on Mac/Linux	source venv/bin/activate
Activate on Windows	venv\Scripts\activate
Deactivate	deactivate
Install a package	pip install package_name
Install specific version	pip install pandas==2.1.4
List installed packages	pip list
Save dependencies	pip freeze > requirements.txt
Install from requirements	pip install -r requirements.txt
Check active Python path	which python (Mac/Linux)
Check active Python path	where python (Windows)
Create with system packages	python -m venv venv –system-site-packages

Virtual environments are not optional for serious Python development. They are the foundation that makes projects reproducible, keeps dependencies clean, and eliminates the version conflict problems that make Python feel chaotic when you are managing multiple projects at once.

The entire workflow comes down to four steps that you will repeat for every project you build. Create the environment with python -m venv venv. Activate it with the appropriate command for your operating system. Install your packages with pip. Save them with pip freeze > requirements.txt. Everything else, deactivating when done, recreating from requirements on a new machine, keeping venv out of version control, follows naturally from understanding those four steps.

Start using virtual environments on every Python project you build from this point forward, even small scripts and quick experiments. The habit costs nothing when the project is small and saves significant time when the project grows or needs to run on another machine.

FAQs