Virtual environments

As Python programs grow beyond a single file, they begin to depend on external packages. Different projects often need different versions of the same package, or entirely different sets of dependencies. This lesson exists to introduce virtual environments, which are the standard way Python projects stay isolated, predictable, and reproducible.

Virtual environments matter immediately once we start building real programs, including AI-capable systems that rely on third-party libraries. They provide a clean boundary between projects without requiring multiple Python installations.

What a virtual environment is

A virtual environment is a self-contained Python workspace. It has its own Python interpreter, its own package directory, and its own installed dependencies.

When we work inside a virtual environment, Python and pip operate only within that environment. Packages installed there do not affect the system-wide Python installation or other projects.

This isolation is the core idea. Each project gets its own controlled environment.

Creating a virtual environment

Python includes built-in support for virtual environments through the venv module. Creating one produces a directory that contains everything needed for isolation.

From a project directory, we create a virtual environment like this:

python -m venv .venv

This command creates a folder named .venv containing a private Python runtime and package space. The name is conventional, but not required.

At this point, the environment exists but is not yet active.

Activating and deactivating a virtual environment

Activating a virtual environment changes the current shell so that python and pip point to the environment instead of the system Python.

On Windows:

.venv\Scripts\activate

On macOS or Linux:

source .venv/bin/activate

Once activated, commands like python and pip operate inside the environment. Deactivating returns the shell to its previous state:

deactivate

Activation is a shell-level concern. It does not modify Python code.

Installing packages inside a virtual environment

When a virtual environment is active, package installation is automatically scoped to it. No special flags are required.

For example, installing a package looks the same as before:

pip install requests

The difference is where the package is installed. It now lives only inside the active environment and is available only when that environment is active.

This allows different projects to depend on different package versions without conflict.

Why virtual environments are important

Virtual environments keep projects independent. They prevent accidental dependency clashes and make it clear which packages a project actually relies on.

They also make projects easier to share, deploy, and reproduce. When dependencies are isolated, a project behaves the same way regardless of what is installed elsewhere on the system.

For Python-based AI systems, where dependencies change quickly and compatibility matters, virtual environments are not optional. They are part of the normal workflow.

Conclusion

We introduced virtual environments as isolated Python workspaces, saw how to create and activate them, and used them to install packages safely. The goal was orientation: understanding why virtual environments exist and how they fit into real Python projects.

With this mental model in place, we are ready to use virtual environments as the default foundation for any non-trivial Python program.