Python virtual environments: isolation without the chaos

Global package installs are a recipe for conflict

Installing packages globally on your system can break applications. Different projects often require conflicting versions of the same dependency.

The solution is to install packages locally, within isolated project environments. This principle of isolation is a core tenet of modern development, driving the adoption of containers and, at the language level, virtual environments.

What a Python virtual environment does

A Python virtual environment is a self-contained workspace inside a project directory. It includes its own Python interpreter, package installer (pip), and libraries.

This isolation means changes in one project don’t affect another. For example, Project A can use requests library version 2.25 while Project B uses version 2.31, side-by-side without conflict.

• Prevents version conflicts between projects.
• Makes applications easier to maintain and update independently.
• Allows for safe experimentation without risking system stability.

How to build and use virtual environments

This tutorial creates two virtual environments in one project to demonstrate isolation. Ensure you have Python installed before starting.

First, create a new project directory and navigate into it.

Creating the isolated environments

We will create two virtual environments named venv_old and venv_new.

Successful creation adds two new folders, venv_old and venv_new, to your project directory.

Activating and working in the first environment

Activate venv_old from the parent directory (build_venv). Your terminal prompt will change to show (venv).

Install the numpy package into this active environment. This install is local to venv_old only.

Running a script with dependencies

Create a main.py file in the project root that requires NumPy to run.

Add the following code to main.py:

Run the script. The command may be python, python3, or another alias on your system.

The script executes successfully, printing a random number, because NumPy is installed in the active venv_old environment.

Switching to the second, empty environment

First, deactivate the current environment.

Now activate the second environment, venv_new.

Attempt to run the same main.py script again.

The script now fails with an error, because venv_new does not have NumPy installed. This demonstrates the isolation: packages in one environment are unavailable in another.

How Python resolves dependencies without an environment

If you deactivate venv_new and run main.py with no virtual environment active, it may still succeed. Python will then use any globally or user-installed version of NumPy it can find.

This fallback behavior highlights the core purpose of virtual environments: they override the default package resolution path to provide precise, project-specific control. Without one, you are at the mercy of your system's global state.

Virtual environments provide essential control

This simple exercise shows how virtual environments prevent dependency chaos. They allow developers to maintain multiple projects with conflicting requirements on a single machine.

Isolating dependencies is a best practice that scales from small scripts to large applications, saving significant maintenance headaches and enabling safe experimentation.