Python Tutorial: virtualenv and why you should use virtual environments

TL;DR

Use virtual environments to isolate dependencies so one project’s package upgrades don’t break others that need different versions.

Briefing Cornell Notes

Briefing

Virtual environments (virtualenv) let Python developers isolate dependencies per project, preventing package upgrades from breaking other applications that rely on different versions. Instead of sharing one global set of installed libraries, each project can run inside its own environment with only the packages—and specific versions—that project needs. That isolation matters most when multiple apps depend on the same framework (like Flask or Django) but require different releases; upgrading a shared global dependency can silently break working sites.

The tutorial demonstrates the workflow end to end. After confirming that global site-packages contain many libraries at fixed versions, it creates a dedicated folder named “environments” to store virtual environments. Inside that directory, it runs `virtualenv project1orEnv` to create the first environment. Creating the environment automatically installs tooling like `pip` and `setuptools`, so the new environment is immediately ready for package installation.

Activation is handled through a shell command: `source <env-name>/bin/activate`. Once activated, the environment name appears in the command prompt, and `which python` and `which pip` point to executables inside the environment’s directory. A `pip list` now shows only the packages installed within that environment—initially just `pip` and `setuptools`. The tutorial then installs libraries (including `numpy`, `psycopg2`, and `pytz`), verifies them with another `pip list`, and captures the exact installed versions using `pip freeze`.

To move those dependencies to another machine or project, it writes the frozen output to `requirements.txt` (via `pip freeze > requirements.txt`). Later, another environment can recreate the same dependency set by running `pip install -r requirements.txt`, ensuring version consistency.

Switching back to the global Python setup is as simple as running `deactivate`, which removes the environment prompt marker and restores access to the global `python` and global installed packages. The tutorial also shows how to remove an environment entirely by deleting its folder (e.g., `rm -rf project1orEnv`).

Finally, it creates a second environment that targets a specific Python version using `virtualenv` with a Python interpreter path (it demonstrates `python2.6`), activates it, checks the interpreter version, and installs the earlier `requirements.txt` contents to match dependencies precisely.

A key practical note closes the loop: virtual environments are for dependencies, not for housing project source code. Developers should keep application files outside the environment and use the environment only to manage packages and versions that can be discarded or recreated safely.

Cornell Notes

Virtual environments isolate Python dependencies so different projects can use different package versions without interfering with each other. After creating an environment with `virtualenv`, activating it changes which `python` and `pip` executables are used, and `pip list` shows only that environment’s installed packages. Dependencies can be exported with `pip freeze` into a `requirements.txt` file and later installed in another environment using `pip install -r requirements.txt`. Running `deactivate` returns to the global Python setup, and deleting the environment folder removes the isolated packages entirely. Virtual environments manage dependencies only; project code should live outside them.

Why can upgrading a global package break multiple projects, and how does virtualenv prevent that?

If several projects share one global site-packages directory, they also share the same installed library versions. Upgrading a shared dependency (for example, a Flask or Django version) can change behavior for every project that relies on the old version. virtualenv avoids this by creating separate environments, each with its own installed packages and versions, so one project’s dependency changes don’t affect another.

What changes after activating a virtual environment, and how can you verify it?

Activation updates the shell so the environment’s executables are used. The prompt shows the environment name, and `which python` points to something like `<env>/bin/python` rather than the global interpreter. Similarly, `which pip` points to `<env>/bin/pip`, and `pip list` shows only packages installed inside that environment (initially just `pip` and `setuptools`).

How do you capture exact dependency versions from one environment for reuse elsewhere?

Use `pip freeze` to output installed packages with version numbers, then redirect to a file such as `requirements.txt` (e.g., `pip freeze > requirements.txt`). That file becomes a reproducible dependency manifest for another environment.

How do you recreate the same dependencies in a new virtual environment?

After creating and activating a new environment, run `pip install -r requirements.txt`. This installs the packages listed in the requirements file, including the specific versions, so the new environment matches the original dependency set.

How do you switch back to global Python and remove an environment completely?

To switch back, run `deactivate`, which removes the environment prompt marker and restores global `python`/`pip` behavior. To remove the environment, delete its directory (for example, `rm -rf project1orEnv`), since the environment is just a folder containing isolated packages and executables.

How can a virtual environment be tied to a specific Python version?

When creating the environment, virtualenv can be pointed at a particular interpreter path (the tutorial demonstrates using `python2.6`). After activation, `python --version` confirms the environment is using that specific Python release, and then `pip install -r requirements.txt` installs the dependencies into that version-specific environment.

Review Questions

What specific commands confirm that `python` and `pip` are coming from the active virtual environment rather than the global installation?
How does `pip freeze` differ from `pip list`, and why does `requirements.txt` matter for reproducibility?
What is the correct workflow for switching projects using virtualenv, and what should never be placed inside the environment?

Key Points

1
Use virtual environments to isolate dependencies so one project’s package upgrades don’t break others that need different versions.
2
Create environments in a dedicated directory (like an “environments” folder) to keep them organized.
3
Activate an environment with `source <env>/bin/activate` and verify isolation using `which python` and `pip list`.
4
Export exact dependency versions with `pip freeze > requirements.txt` and recreate them with `pip install -r requirements.txt`.
5
Switch back to global Python using `deactivate`, and remove an environment by deleting its folder.
6
Virtual environments manage dependencies only; keep project source code outside the environment directory.
7
Create Python-version-specific environments by pointing virtualenv at the desired interpreter (e.g., `python2.6`).

Highlights

virtualenv prevents dependency conflicts by giving each project its own isolated set of packages and versions.

`pip freeze` plus `requirements.txt` turns an environment into a reproducible dependency recipe.

Activating a virtual environment changes which `python` and `pip` executables are used, which you can confirm with `which python` and `which pip`.

Deleting the environment folder fully removes the isolated packages, making cleanup straightforward.

Topics

Virtual Environments
Dependency Isolation
pip freeze
requirements.txt
Python Versioning