Python Virtual Environments Explained: venv vs virtualenv vs pyenv vs pipenv

By the end of this page, you will understand what a Python virtual environment is, what venv does, and how it differs from tools like virtualenv, pyenv, virtualenvwrapper, and pipenv. You will also learn when each tool is useful, how they can work together, and which tool is the simplest choice for most beginner projects.

A virtual environment in Python is an isolated folder that contains its own Python executable and installed packages. Its main purpose is to let one project use its own dependencies without affecting other projects on the same machine.

For example:

• Project A may need Django 4.x
• Project B may need Flask 3.x
• Project C may need an older library version for compatibility

Without isolation, installing packages globally can cause version conflicts.

What venv does

venv is the built-in standard library tool for creating virtual environments in Python 3. It creates a self-contained environment for a specific project.

Example:

python -m venv .venv

This creates a directory named .venv containing:

• a Python interpreter
• a place for installed packages
• activation scripts

After activation, commands like python and pip use that environment instead of the global Python installation.

Why there are many similar tools

Different tools solve different layers of the same general problem:

• venv: create isolated environments
• virtualenv: older and more feature-rich environment creator
• pyenv: switch between Python versions installed on your machine
• virtualenvwrapper: convenience commands for managing many virtual environments
• pipenv: combine dependency management and virtual environments
• pyvenv: older command related to venv, now mostly obsolete

These tools are not all direct competitors. Some overlap, but some solve different problems.

Why this matters

In real programming, projects often need:

• isolated dependencies
• reproducible installs
• different Python versions
• easy project setup for teams

Understanding the role of each tool helps you pick the simplest workflow instead of combining tools unnecessarily.

Think of Python development like cooking in different kitchens.

• Global Python is one big shared kitchen in your house.
• A virtual environment is a separate kitchen counter for one recipe, with only the tools and ingredients that recipe needs.
• venv / virtualenv build that separate counter.
• pyenv decides which house or kitchen model you are using, such as Python 3.10 or Python 3.12.
• virtualenvwrapper is like labeling and organizing all your kitchen counters so you can switch between them easily.
• pipenv is like a kit that tries to manage both the counter and the shopping list for ingredients.

So:

• If you need package isolation, use a virtual environment tool.
• If you need different Python versions, use a Python version manager.
• If you want dependency files plus automatic environment creation, use a workflow tool like pipenv.

Create a virtual environment with venv

python -m venv .venv

Activate it:

macOS / Linux

source .venv/bin/activate

Windows

.venv\Scripts\activate

Install a package:

pip install requests

Check where Python is coming from:

python -c "import sys; print(sys.executable)"

This should point to the Python executable inside .venv.

Equivalent idea with virtualenv

virtualenv .venv
source .venv/bin/activate

virtualenv does roughly the same job as venv: it creates an isolated environment.

Using pyenv

pyenv install 3.12.3
pyenv local 3.12.3
python -V

This does not create a virtual environment by itself. It selects which Python version your project should use.

Using pipenv

pipenv install requests
pipenv shell

This creates or uses a virtual environment and records dependencies in Pipfile and Pipfile.lock.

Quick interpretation

• venv: built-in environment creation
• virtualenv: third-party environment creation
• pyenv: Python version selection
• pipenv: dependency + environment workflow

Consider this sequence:

python -m venv .venv
source .venv/bin/activate
pip install requests
python -c "import requests; print(requests.__version__)"

What happens step by step

1. python -m venv .venv

Python runs the built-in venv module.

It creates a new folder named .venv containing:

• a Python executable
• site-packages for installed libraries
• scripts for activation

2. source .venv/bin/activate

Your shell updates environment variables so that when you type python or pip, the versions inside .venv are used first.

This usually changes your prompt to show the environment name.

3. pip install requests

pip installs requests into the .venv environment, not into the global Python installation.

4. python -c "import requests; print(requests.__version__)"

Python runs inside the active environment, imports requests, and prints its installed version.

Important detail

If you deactivate the environment:

deactivate

then python and pip return to your normal global installation.

That is the key idea of environment isolation.

1. Keeping project dependencies separate

A web API may need one set of packages, while a data analysis script needs another. Virtual environments prevent package conflicts.

2. Working on multiple projects with different package versions

You might maintain:

• one project using Django 5
• another using Django 4

Each project can have its own environment.

3. Testing code against different Python versions

Use pyenv to install Python 3.10, 3.11, and 3.12, then create separate environments for testing.

4. Team collaboration

A project can include a dependency file, and each developer creates their own isolated environment locally.

5. Safe experimentation

If you want to try a new package without affecting your system Python, create a temporary virtual environment first.

In real projects, developers often combine tools rather than using only one.

Common patterns

Pattern 1: pyenv + venv

A very common setup:

1. Use pyenv to choose the Python version for the project
2. Use venv to isolate project dependencies

Example:

pyenv local 3.12.3
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

This is a clean and popular workflow.

Pattern 2: virtualenvwrapper for many environments

If you manage many environments, virtualenvwrapper adds helper commands like:

• mkvirtualenv
• workon
• rmvirtualenv

This is about convenience, not a different isolation model.

Pattern 3: pipenv for dependency tracking

Some teams prefer pipenv because it manages:

• a virtual environment
• dependency declarations
• lock files

Example:

pipenv install flask
pipenv install --dev pytest

Common codebase habits

• put the environment in .venv/
• add .venv/ to .gitignore
• pin dependencies for reproducible installs
• avoid installing project dependencies globally
• document setup steps in README.md

Guard against confusion

A common mistake in teams is mixing tools without a plan. For example, using pyenv, conda, venv, and pipenv all at once can make the environment hard to debug. Most codebases work best with one clear workflow.

1. Confusing Python version management with virtual environments

Beginners often think pyenv replaces venv.

It does not.

• pyenv manages which Python version is used
• venv manages isolated packages for a project

2. Installing packages globally by accident

Broken workflow:

pip install requests

If no environment is active, this may install globally.

Better:

python -m venv .venv
source .venv/bin/activate
python -m pip install requests

Using python -m pip helps ensure you use the pip tied to the active interpreter.

3. Committing the virtual environment to Git

Do not commit .venv/ or other environment folders.

Add this to .gitignore:

.venv/

4. Assuming pyvenv is the recommended modern tool

pyvenv was an older helper command associated with venv. Modern usage generally prefers:

python -m venv .venv

5. Mixing dependency files casually

A project should usually have a clear approach, such as:

• requirements.txt
• or Pipfile
• or another single dependency system

Using several without understanding why can confuse installation.

6. Forgetting to activate the environment

You may create the environment correctly but still run the wrong Python.

Check with:

python -c "import sys; print(sys.executable)"

7. Expecting venv to install Python itself

venv creates an environment from an existing Python interpreter. It does not download and install new Python versions.

venv vs virtualenv

• venv is built into Python 3
• virtualenv is a third-party package
• both create virtual environments
• virtualenv historically offered broader compatibility and extra features
• for many modern Python 3 projects, venv is enough

venv vs pyenv

• venv isolates packages per project
• pyenv chooses which Python version the project uses

These are complementary, not equivalent.

virtualenvwrapper vs virtualenv

• virtualenv creates the environment
• virtualenvwrapper provides helper commands for organizing and switching between environments

pipenv vs venv

• venv only creates the environment
• pipenv creates an environment and tracks dependencies in dedicated files

Simple recommendation

For beginners, a good default is:

• use venv for isolation
• optionally use pyenv if you need multiple Python versions

Quick definitions

• venv: built-in Python 3 module for virtual environments
• pyvenv: older command related to venv; generally avoid using it now
• virtualenv: third-party virtual environment tool
• virtualenvwrapper: convenience layer for managing many virtualenvs
• pyenv: install and switch Python versions
• pipenv: dependency manager that also creates virtual environments

Most common commands

Create env with venv

python -m venv .venv

Activate on macOS/Linux

source .venv/bin/activate

Activate on Windows

.venv\Scripts\activate

Deactivate

deactivate

Install packages into current env

python -m pip install requests

Save dependencies

python -m pip freeze > requirements.txt

Rules of thumb

• Need isolated packages? Use venv
• Need multiple Python versions? Use pyenv
• Need convenience for many envs? Use virtualenvwrapper
• Need dependency file workflow with automatic env handling? Use pipenv

Beginner-safe default

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

Edge cases

• venv does not install Python versions
• pyenv does not replace venv
• pipenv is a workflow tool, not just an environment creator
• pyvenv is largely historical

What is the difference between venv and virtualenv?

venv is the standard library solution in Python 3, while virtualenv is a third-party package that also creates virtual environments and historically supported more scenarios.

Is pyenv the same as a virtual environment?

No. pyenv manages Python versions installed on your machine. It does not mainly exist to isolate project packages.

Should I use venv or pipenv?

If you want the simplest standard approach, use venv. If you want a tool that also manages dependency files and lock files, pipenv may be useful.

Is pyvenv deprecated?

In modern practice, python -m venv is the preferred command. pyvenv is mostly an older command and is generally not the recommended modern choice.

Can I use pyenv and venv together?

Yes. This is a common setup: use pyenv to pick the Python version, then use venv to isolate dependencies for the project.

Why should I avoid global pip install?

Global installs can create version conflicts between projects and may affect system tools. Virtual environments keep project dependencies separate.

Do I need to commit my virtual environment folder?

No. Usually you commit dependency files, not the environment folder itself.

What is the easiest option for beginners?

For most beginners, venv is the best starting point because it is built in, simple, and widely used.

• Python package management — related because virtual environments are commonly used with pip.
• pip — the tool used to install packages inside a virtual environment.
• requirements.txt — commonly used to record project dependencies.
• Python interpreter — important because tools like pyenv change which interpreter is used.
• Dependency isolation — the core reason virtual environments exist.
• PATH and shell environment variables — activation works by changing command resolution.
• Project reproducibility — environment and dependency tools help teams recreate the same setup.
• Conda — another environment and package management system often compared with venv-based workflows.