What a virtual environment does and why you need one

A virtual environment is a folder on your computer that holds a separate copy of Python and its packages, isolated from the rest of your system. When you create one, you get a sandbox where you can install libraries and tools for a specific project without affecting Python elsewhere on your machine.

This matters because different projects often need different versions of the same package. Project A might need version 2.0 of a library, while Project B needs version 3.0. Without virtual environments, installing version 3.0 would break Project A. A virtual environment lets each project have exactly what it needs.

Virtual environments also keep your system Python clean. Your operating system may depend on Python for its own tools, so installing random packages into system Python can cause problems. A virtual environment protects against that.

Key Takeaways

  • A virtual environment is a folder containing an isolated copy of Python and its packages, created with the venv module that comes built into Python 3.
  • You create one by opening your terminal or command prompt, navigating to your project folder, and running python -m venv env (or another name instead of env).
  • After creating it, you must set up the environment by running a script inside it—the command differs between Windows, Mac, and Linux.
  • Once activated, any packages you install with pip go into that environment only, leaving your system Python untouched.
  • You deactivate an environment by typing deactivate in the terminal, returning to your system Python.

Creating a virtual environment on Windows

Open Command Prompt or PowerShell and navigate to the folder where your project lives. If your project folder is called my_project and it sits on your Desktop, you would type cd Desktop\my_project and press Enter.

Once you are inside the project folder, type this command and press Enter:

python -m venv env

Python will create a folder called env inside your project. This folder contains the isolated Python installation. The process takes a few seconds. You will see no message when it finishes—that is normal.

Next, set up the environment by running the set up script. Type this and press Enter:

env\Scripts\set up

When the environment is active, your command prompt will show (env) at the start of the line. That tells you the virtual environment is running. Now any package you install stays inside this env folder.

Creating a virtual environment on Mac and Linux

Open Terminal and navigate to your project folder using cd. For example, if your project is in a folder called my_project in your home directory, type cd my_project and press Enter.

Create the virtual environment with this command:

python3 -m venv env

Note that on Mac and Linux you use python3, not python. The system will create an env folder. Wait a few seconds for it to finish.

set up the environment by typing:

source env/bin/set up

Press Enter. Your terminal prompt will now show (env) at the beginning, confirming the environment is active. You are now working inside the isolated Python installation.

Installing packages inside your virtual environment

With the virtual environment active (you should see (env) in your prompt), you can install packages using pip, Python's package installer. For example, to install the requests library, type:

pip install requests

Press Enter and pip will read and install the package into your virtual environment only. You can install multiple packages by listing them with spaces: pip install requests flask django.

To see what packages are already installed in your environment, type pip list and press Enter. This shows only the packages in the active virtual environment, not your system Python.

If you want to save a list of what your project needs, type pip freeze > requirements.txt. This creates a file called requirements.txt that lists every package and its version. Later, you or someone else can recreate the exact same environment by running pip install -r requirements.txt.

Deactivating and reactivating your environment

When you are done working on your project, type deactivate and press Enter. The (env) will disappear from your prompt, and you are back to using your system Python. The virtual environment folder stays on your computer—deactivating just stops using it.

The next time you want to work on that project, navigate to the project folder and set up the environment again using the same command you used before: env\Scripts\set up on Windows, or source env/bin/set up on Mac and Linux.

You only create the virtual environment once. After that, you just set up and deactivate it as needed. The folder and all the packages inside it persist until you delete the env folder.

Avoiding common mistakes

The most common mistake is forgetting to set up the environment before installing packages. If you run pip install without seeing (env) in your prompt, the package goes into your system Python, defeating the purpose. Always check your prompt first.

Another mistake is creating the virtual environment in the wrong folder. Make sure you are inside your project folder before running python -m venv env. If you create it in your home directory or Desktop by accident, you will have a confusing setup. Delete the env folder and create it again in the correct location.

Some people try to move or rename the env folder after creating it. Do not do this—the paths inside the folder become broken. If you need to move your project, delete the env folder, move the project, and create a new virtual environment in the new location.

On Windows, if you get an error saying "execution of scripts is disabled", you may need to change your PowerShell policy. Run PowerShell as Administrator and type Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser, then try activating again.

When to use virtual environments

Use a virtual environment for every Python project, no matter how small. Even a single script benefits from having its own isolated space. The only exception is if you are just learning Python and running one-off practice scripts—but even then, a virtual environment teaches you the right habit.

If you are working on multiple projects, each one should have its own virtual environment. This prevents version conflicts and makes it straightforward to switch between projects without worrying about package compatibility.

When you share your project with others or upload it to a repository like GitHub, you do not include the env folder—it is too large and specific to each person's computer. Instead, you share the requirements.txt file. Anyone who clones your project can create their own virtual environment and run pip install -r requirements.txt to get the exact same packages.

Frequently Asked Questions

Do I need to create a new virtual environment for every project?

Yes. Each project should have its own virtual environment. This keeps packages isolated and prevents version conflicts between projects. Creating a new one takes seconds and saves hours of debugging later.

What happens if I delete the env folder?

The virtual environment is gone, but your project files remain. You can recreate the environment by running python -m venv env again and then pip install -r requirements.txt if you saved a requirements file. Always keep your requirements.txt file in version control.

Can I use a different name instead of env?

Yes. Instead of python -m venv env, you can type python -m venv venv or python -m venv myenv or any other name. The set up command changes to match—for example, source myenv/bin/set up on Mac and Linux. Most projects use env or venv by convention.

Why does my prompt not show (env) after activating?

On some systems, the prompt does not display the environment name by default. Type pip list to confirm packages are installing into the environment. If you see only a few packages (not your entire system Python), the environment is active even if the prompt does not show it.

Can I have multiple virtual environments in one project?

Technically yes, but you should not. One virtual environment per project is the standard. If you need different package sets for different purposes, use a single environment and manage versions carefully, or create separate projects with separate environments.