Python Virtual Environments: venv, uv, and conda

Why Isolation Matters

Let's go deeper than the surface-level "projects need different versions" answer, because truly understanding isolation changes how you think about Python development at every level.

Python's package ecosystem is vast, over 500,000 packages on PyPI. Each of those packages has its own dependencies, and those dependencies have dependencies. The moment you install anything, you are pulling in a tree of transitive requirements. Now multiply that by every project you work on. Without isolation, all of those trees have to coexist in one flat namespace on your system Python. There are no subfolders for Project A versus Project B. Everything lands in the same site-packages directory, and when two projects need different versions of the same package, only one can win.

Isolation matters for reproducibility, too. When you share code with a teammate or deploy to a server, you need your exact environment to follow you. Without a defined, isolated environment, "works on my machine" becomes a real problem. The server might have a slightly different version of a transitive dependency installed, and suddenly your code behaves differently in production than it did in development.

There is also the system Python to consider. On Linux and macOS, the system Python is not yours, it belongs to the operating system. Package managers and system tools depend on it. When you pip install something globally, you risk breaking OS-level utilities that were written expecting specific package versions. On many Linux systems this can cascade into genuinely broken system tools. Isolation is not just a good practice, it is what keeps your machine stable and healthy over time.

Why Virtual Environments Matter

Let me paint a scenario. You have got Project A that needs Django 3.2, and Project B needs Django 4.1. Both installed in your system Python. You pip install one, then the other. Now they are fighting. One breaks. You are stuck.

Virtual environments solve this by creating isolated Python installations. Each project gets its own directory containing:

• A Python interpreter (or a link to one)
• site-packages/ directory for installed packages
• Activation scripts to switch contexts

Think of them as sandboxes. What you install in one does not affect the others.

Why this matters:

• Different projects can use different package versions
• You can reproduce exact environments on other machines
• Testing across Python versions becomes possible
• You avoid polluting your system Python with random packages

Let's dig into your three main options.

Dependency Hell Explained

"Dependency hell" is not just a cute phrase, it is a real phenomenon with a name in computer science: the diamond dependency problem. Imagine your project depends on Library A and Library B. Library A depends on requests>=2.25. Library B depends on requests<2.27. Your package manager now has to find a version of requests that satisfies both constraints simultaneously. In simple cases, there is a solution: requests==2.26 fits both. But with dozens of packages, each pulling in their own dependencies with their own constraints, the constraint-solving problem becomes combinatorially complex.

This is why sometimes pip install hangs for minutes, it is running a constraint solver trying to find a compatible set of all packages in your dependency graph. When no solution exists, you get an error that can be genuinely difficult to interpret. When the solver finds a "solution" that technically satisfies the version constraints but produces runtime incompatibilities, you get bugs that are even harder to track down.

The problem compounds over time. You install a package today, then six months later update an unrelated package. The update pulls in a new version of a transitive dependency that happens to conflict with something else. Your tests start failing. You run pip list and stare at 47 packages trying to figure out which one changed. This is dependency hell in practice, not a dramatic blowup, but a slow accumulation of fragile state that eventually collapses.

Lock files are the answer. A lock file captures the exact resolved version of every package in your entire dependency tree, including transitive dependencies you never directly asked for. When you deploy or share your code, the lock file lets anyone reproduce your exact environment, bypassing the constraint solver entirely. This is why modern tools like uv prioritize lock files as a first-class feature, not an afterthought.

venv: The Built-In Standard

venv ships with Python 3.3+, so you have got it already. No installation needed. For years, this was the solution, and it is still solid for straightforward projects.

Creating and Activating a venv

The basic workflow is two commands: create and activate. Once activated, any Python-related command you run, whether python, pip, or a script, operates within the isolated environment rather than your system Python.

# Create a virtual environment named 'venv'
python -m venv venv
 
# Activate it (Linux/macOS)
source venv/bin/activate
 
# Activate it (Windows)
venv\Scripts\activate

After activation, your shell prompt changes to show the environment name. This visual cue is important, it tells you at a glance which environment is active, so you do not accidentally install packages into the wrong place:

(venv) $ python --version
Python 3.11.0

Any pip install now goes into venv/lib/python3.11/site-packages/, not your system Python.

The Activation Scripts

What exactly happens when you activate? The activation script does something elegant in its simplicity, it modifies your current shell session's environment variables so that Python-related commands resolve to the virtual environment's versions first. Let us peek:

$ cat venv/bin/activate
# ... lots of shell script ...
# The key line:
VIRTUAL_ENV="/path/to/venv"
export VIRTUAL_ENV
PATH="$VIRTUAL_ENV/bin:$PATH"
export PATH

It modifies your PATH to put the virtual environment's bin/ directory first. Now when you run python, it finds the one in the venv, not your system one. When you run pip, it installs into the venv's site-packages/. The beauty of this approach is that it is purely a shell-level change, deactivating the environment simply restores your original PATH, leaving your system Python completely untouched.

The requirements.txt Workflow

The pip freeze command captures the current state of your environment as a list of pinned package versions. This is the traditional way of sharing environment specifications, and while it has limitations we will cover shortly, it is universally understood and supported by every CI system and deployment platform you will encounter.

pip install requests numpy Flask
pip freeze > requirements.txt

Your requirements.txt looks like:

requests==2.31.0
urllib3==2.1.0
charset-normalizer==3.3.2
idna==3.6
numpy==1.24.3
Flask==3.0.0
# ... more dependencies ...

On another machine (or in CI), recreate the exact environment by creating a fresh venv and installing from the pinned list. This guarantees that every package version matches what you tested against:

python -m venv venv
source venv/bin/activate  # or activate.bat on Windows
pip install -r requirements.txt

The gotcha: pip freeze includes everything, even transitive dependencies. Your requirements.txt becomes hard to maintain. You do not know which packages you explicitly wanted versus which were pulled in as dependencies. This is where uv changes the game.

pip: The Package Installer You Already Use

pip comes with venv automatically. You have probably used it already. The commands are simple and intuitive, the syntax for specifying version constraints follows PEP 440 and is consistent across the entire Python ecosystem:

pip install package_name
pip install package_name==1.2.3  # specific version
pip install package_name>=1.0    # version constraint
pip list                         # see what's installed
pip uninstall package_name       # remove a package

It works fine, but it is slow. Resolving dependencies on a fresh environment can take minutes. It is written in Python, which means it is interpreted and not optimized for speed. For small projects this is barely noticeable, but if you are spinning up environments frequently in CI/CD pipelines, or working with large dependency trees typical in ML projects, the wait times add up to real productivity loss.

Enter uv.

uv: The Modern Fast Alternative

uv is a Rust-based package manager that has been gaining traction rapidly. It is roughly 10-20x faster than pip for most operations. If you have used other modern package managers like Rust's cargo or Node's pnpm, uv follows similar patterns, a single tool that handles both environment management and package installation, with lock files as a first-class citizen rather than a workaround.

Installing uv

Installing uv itself is a one-time operation. The recommended approach is the official installer script, which downloads a precompiled binary and adds it to your PATH. Once installed, uv manages everything else, you will rarely need to touch the installer again:

# macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
 
# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
 
# Or via pip (ironic, but works)
pip install uv

Creating and Using a uv Virtual Environment

The surface-level commands look similar to what you already know from venv and pip, which makes adoption easy, you are not learning a completely alien workflow, just a faster version of the one you already have. The key differences emerge when you start using uv's project management features:

# Create a venv with uv
uv venv
 
# Activate it (same as venv)
source .venv/bin/activate  # Linux/macOS
.venv\Scripts\activate      # Windows
 
# Install packages
uv pip install requests numpy Flask
 
# List installed packages
uv pip list
 
# Remove packages
uv pip uninstall requests

So far, it looks like pip. The magic is under the hood, uv pip is dramatically faster because it is Rust.

The uv.lock File

Here is where uv genuinely changes your workflow for the better. The separation between what you directly depend on (listed in pyproject.toml) and the full resolved dependency tree (captured in uv.lock) gives you a clean mental model that requirements.txt has never been able to provide. You edit pyproject.toml to express your intentions; uv does the work of resolving and locking the rest:

# pyproject.toml
[project]
name = "my-project"
version = "0.1.0"
dependencies = [
    "requests>=2.28.0",
    "numpy>=1.24.0",
    "Flask>=3.0.0",
]

Now generate a lock file:

uv sync

This creates uv.lock, which contains every exact version, including transitive dependencies. Unlike requirements.txt, the lock file also includes cryptographic hashes for every package, so you can detect tampering or corruption:

[[distribution]]
name = "requests"
version = "2.31.0"
source = { type = "registry", url = "https://pypi.org/simple" }
# ... hashes and dependency info ...

[[distribution]]
name = "urllib3"
version = "2.1.0"
source = { type = "registry", url = "https://pypi.org/simple" }
# ... hashes and dependency info ...

The difference from pip freeze is crucial: uv.lock is deterministic and cryptographically verified. On another machine, the workflow could not be simpler, one command reproduces your exact environment, runs the constraint solver from the lock file rather than from scratch, and verifies package integrity in the process:

uv sync

You get exactly the same versions, every time. No surprises.

uv for Multiple Python Versions

uv handles this elegantly without requiring a separate tool like pyenv for most use cases. You can specify the Python version at environment creation time, and uv will download and manage that Python version for you if it is not already installed on the system:

# Install Python 3.9 (if you don't have it)
uv python install 3.9
 
# Create a venv with that version
uv venv --python 3.9
 
# Or for a project, update pyproject.toml
[project]
requires-python = ">=3.9,<4.0"
 
# Then sync
uv sync

Compare this to the venv + pyenv dance we will discuss next. It is simpler.

conda: The Data Science Heavyweight

If venv + pip is the standard, conda is the specialized tool for data scientists. The distinction matters and is worth understanding clearly: pip installs Python packages, period. Conda installs packages from a broader ecosystem that can include compiled C/C++/Fortran libraries. NumPy needs BLAS. SciPy needs LAPACK. TensorFlow needs CUDA libraries. These are not Python packages, they are binary system libraries that need to be compiled for your specific architecture and OS. Conda compiles and manages them for you.

# Pure pip + venv approach
pip install numpy scipy scikit-learn
 
# Works fine, but what if you're on a machine with weird BLAS setup?
# Good luck. You're debugging C library linking issues.
 
# Conda approach
conda install numpy scipy scikit-learn
 
# Conda handles the BLAS/LAPACK for you. No headaches.

Installing Conda

You have two choices when getting started with conda. Miniconda is the minimal installer, just conda itself and its dependencies, roughly 400MB. Anaconda is the full distribution with over 1,500 pre-installed packages, targeting users who want everything ready to go. For most developers, Miniconda is the right starting point because it keeps you in control of what gets installed:

# Miniconda (lightweight, recommended for most)
# Download from https://docs.conda.io/projects/miniconda/
 
# Or Anaconda (full stack, includes 1000+ packages)
# Download from https://www.anaconda.com/

Creating and Using Conda Environments

Conda environments work differently from venv environments in one important way: they are stored in a central location managed by conda, not in a local subdirectory of your project. This means you reference them by name rather than by path. You can have as many named environments as you want and switch between them freely from any directory:

# Create an environment
conda create -n my-project python=3.11
 
# Activate it
conda activate my-project
 
# Install packages (conda or pip)
conda install requests numpy Flask
 
# Or mix conda and pip
conda install pytorch::pytorch pytorch::torchvision -c pytorch
pip install wandb
 
# List environments
conda env list
 
# Remove an environment
conda remove -n my-project --all

Environment Files with Conda

Exporting a conda environment captures both the conda-installed packages and any pip-installed packages within that environment, all in a single YAML file. This portability is one of conda's strongest features for sharing reproducible data science environments across teams:

conda env export > environment.yml

This creates:

name: my-project
channels:
  - conda-forge
  - pytorch
  - defaults
dependencies:
  - python=3.11
  - numpy=1.24.3
  - pytorch::pytorch
  - pip
  - pip:
      - wandb==0.15.0

Recreating the environment on another machine is a single command that handles both the conda and pip portions of the dependency tree, respecting the channel priorities you specified:

conda env create -f environment.yml

The tradeoff: Conda is slower than uv, the dependency resolver can be mysterious (it is a complex constraint solver), and the ecosystem is not as standardized. But for data science, the automatic handling of system dependencies is worth it.

venv vs conda vs uv Comparison

Let us put these tools side by side to make the decision process concrete. Understanding the tradeoffs is not about picking a winner, each tool genuinely excels in its intended context, and the "right" choice depends entirely on what you are building.

The pattern that works well for most new projects today is uv for everything except heavy data science work, where conda earns its complexity. The built-in venv remains the right choice when you need zero-dependency tooling or when working in environments where only standard Python tools are available.

Managing Multiple Python Versions with pyenv

What if you need Python 3.9, 3.10, and 3.11 on the same machine? pyenv manages multiple Python installations, letting you install any version and switch between them at the global, local (per-directory), or shell level. This is particularly useful when you are maintaining libraries that need to support multiple Python versions:

# Install pyenv
# macOS: brew install pyenv
# Linux: https://github.com/pyenv/pyenv
 
# List available versions
pyenv versions
 
# Install a version
pyenv install 3.9.18
pyenv install 3.11.7
 
# Set global version
pyenv global 3.11.7
 
# Set per-project version
cd /path/to/project
pyenv local 3.9.18
 
# Now in that directory, Python 3.9 is used
python --version
# Python 3.9.18

Then combine with venv to get both version management and package isolation in a workflow that has been battle-tested for years across the Python community:

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

Or with uv, which can discover and use pyenv-managed Python installations automatically:

uv venv --python 3.9  # uv finds the Python 3.9 from pyenv
uv sync

Comparison: Which One to Use?

Let's be practical. Here is the decision tree:

Use venv + pip if:

• You are learning Python or working on a simple script
• You are in a corporate environment with locked-in pip workflows
• You need maximum compatibility (works everywhere)

Use uv if:

• You want speed and modern tooling
• You are starting a new project and want to adopt current best practices
• You like cargo or similar modern package managers
• Your team values reproducibility (lock files)

Use conda if:

• You are doing data science, ML, or scientific computing
• You need to manage non-Python dependencies (BLAS, CUDA, etc.)
• You are working in an academic or research environment
• Your packages come from conda-forge

Use pyenv when:

• You develop against multiple Python versions
• You need a specific Python patch version for compatibility
• You are testing libraries that should support 3.9, 3.10, 3.11

Pro tip: These are not mutually exclusive. You can use pyenv to manage Python versions, uv venv to create environments, and uv pip to install packages. Or mix conda for environment management and uv pip for faster installs. The ecosystem has evolved to be composable.

A Real Example: Setting Up a Flask Project

Let me show you the full workflow with uv, this is the setup pattern we recommend for new Python web projects in 2025 and beyond. Notice how the workflow stays out of your way: create, activate, install, and your environment is both reproducible and fast to recreate on any machine:

# Create a project directory
mkdir my-flask-app
cd my-flask-app
 
# Initialize with uv
uv venv
 
# Activate
source .venv/bin/activate
 
# Install Flask and dependencies
uv pip install Flask requests python-dotenv
 
# Generate lock file
uv sync
 
# Check what got installed
uv pip list
# name                      version
# ----- ----------------------
# Flask                     3.0.0
# Jinja2                    3.1.2
# MarkupSafe                2.1.3
# Werkzeug                  3.0.1
# blinker                   1.7.0
# click                      8.1.7
# itsdangerous              2.1.2
# requests                  2.31.0
# urllib3                   2.1.0

To ship this to production or share with teammates, you commit both pyproject.toml and uv.lock to your repository. The lock file is not optional, it is the entire point. Anyone who clones your repo gets the exact same environment:

# They just do:
uv sync
 
# Boom. Exact same environment.

No pip freeze headaches. No "works on my machine." No dependency resolution arguments.

Common Environment Mistakes

Even experienced developers fall into the same traps with virtual environments. Knowing these pitfalls ahead of time saves you hours of confused debugging.

The most common mistake is forgetting to activate the environment before installing packages. You pip install something, then scratch your head wondering why Python cannot find it when you run your code. The fix is building the habit of checking your prompt before any install command. A second related mistake is activating an environment, installing packages, then opening a new terminal tab, that new tab does not inherit the activation from the previous one, so you are back to system Python without realizing it.

Another frequent error is committing the virtual environment directory itself to git. Virtual environments are large (often hundreds of megabytes), machine-specific, and completely regenerable from your lock file. They should never be in version control. Similarly, people often forget to commit updated lock files after adding a new package. You install something locally and it works, but your teammate's environment is missing the package because the lock file was not updated before the commit.

Mixing conda and pip carelessly is another source of pain. Conda has its own dependency solver, and when you pip-install packages inside a conda environment, conda does not know about those pip packages. This can lead to solver conflicts where conda tries to modify a package that pip installed, or vice versa. The safest practice is to install as much as possible through conda, and only use pip for packages that are not available on conda-forge.

Finally, using overly loose version constraints in pyproject.toml or requirements.txt is a subtle but serious mistake. Writing requests with no version constraint means your environment resolves to whatever the latest version is at install time, which changes over months and years. Always pin or constrain your top-level dependencies, and use lock files to freeze the entire tree.

Common Gotchas

Forgetting to activate. You will install packages globally and wonder why they are not in your project. Check your which python or where python. The difference in output immediately tells you whether you are in your virtual environment or not:

# Wrong (system Python)
$ which python
/usr/bin/python
 
# Right (venv Python)
$ which python
/path/to/venv/bin/python

Committing venv to git. Your virtual environment is machine-specific and huge (hundreds of MB). Add to .gitignore:

venv/
.venv/
env/
conda-env/
__pycache__/

Using pip in conda environments. You can mix conda and pip, but conda's solver can get confused. General rule: use conda for heavy dependencies, pip for lightweight packages.

Forgetting to update requirements.txt/uv.lock. You install a new package locally but forget to update your lock file. Teammate gets broken code. Either:

# With pip
pip install new-package
pip freeze > requirements.txt
 
# With uv
uv pip install new-package
uv sync  # updates uv.lock

Then commit the lock file.

Summary

Virtual environments are non-negotiable in Python development. Pick your tool:

• venv + pip: The classic, built-in, universally compatible option
• uv: The modern, fast, deterministic option for general Python development
• conda: The specialized tool for data science with system dependency management
• pyenv: The companion tool for managing multiple Python versions

Most new Python projects should default to uv, it gives you the speed and reproducibility of modern tooling without the data-science-specific overhead of conda. But understand all three, because you will encounter them in different contexts.

Conclusion

We have covered a lot of ground in this article, and it is worth taking a moment to see the bigger picture. Virtual environments are not a bureaucratic checkbox, they are the foundation that makes everything else in Python development reliable and reproducible. The hour you spend setting up proper environment management at the start of a project saves you days of debugging environment-related issues later. That is not an exaggeration.

Start with the mental model: your project is a box, and the environment defines exactly what is in that box. When you ship the box to a server, to a teammate, or to your future self six months from now, the contents need to be identical to what you tested. Lock files are how you ensure the box's contents never change without your knowledge.

The tooling landscape has improved dramatically in recent years. uv in particular represents a generational leap in developer experience for Python packaging, the speed difference alone is worth the minor learning curve, but the lock file workflow and built-in Python version management make it genuinely superior for most use cases. If you are starting fresh today, start with uv. If you are in data science, learn conda, its ability to manage system-level scientific libraries is genuinely irreplaceable in that domain.

Whatever tool you choose, the most important principle remains constant: always pin your dependencies. Version-pin in your project configuration, commit your lock file, and never let "it works on my machine" be an acceptable answer. Your future self, dealing with a production outage at 2am, will thank you for the discipline you exercised when the stakes were low.