Day 21 — Virtual Environment and pip

What is it? #

A virtual environment is a private folder holding a copy of Python and the packages for one project. Activate it and python and pip refer to that copy instead of the system-wide one.

Without it, everything you install goes into one shared place. Two projects that need different versions of the same library cannot both work, and upgrading for one breaks the other.

pip is the installer. pip install requests downloads a package and its dependencies into the active environment.

A requirements.txt file records what your project needs so someone else — or a server — can recreate the same environment. Pinning exact versions is what makes builds reproducible.

Think of it like this #

A virtual environment is a separate toolbox per job. The plumbing job has its own wrenches; the electrical job has its own testers. Nobody has to argue about which spanner lives in the one shared drawer, and taking a tool out of one box never affects the other.

Simple example #

You start a new project, create an environment for it, install two packages, freeze the versions, and hand the project to a colleague who recreates it exactly.

Code #

# 1. Create the environment (a folder called .venv)
python -m venv .venv

# 2. Activate it
source .venv/bin/activate        # macOS / Linux
.venv\Scripts\activate           # Windows

# The prompt now shows (.venv)

# 3. Install packages into this environment only
pip install requests fastapi

# 4. See what is installed
pip list

# 5. Record exact versions
pip freeze > requirements.txt

# 6. Leave the environment
deactivate

# requirements.txt
fastapi==0.115.0
requests==2.32.3

# On another machine — recreate it exactly
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

# .gitignore — never commit the environment itself
.venv/
__pycache__/
*.pyc
.env

How it works #

python -m venv .venv runs the built-in venv module and creates a .venv folder containing a Python interpreter and an empty site-packages directory.

Activating it changes your shell's PATH so that python and pip resolve to the ones inside .venv. Nothing is installed globally, and nothing is permanent — deleting the folder removes the environment completely.

pip install requests fastapi fetches those packages plus everything they depend on. All of it lands inside .venv.

pip freeze prints every installed package with its exact version, including transitive dependencies. Redirecting it into requirements.txt captures the state of a working environment.

pip install -r requirements.txt reads that file and installs the same versions. This is how a server ends up running exactly what you tested.

The .gitignore entries matter. The environment folder is large, machine-specific and rebuildable, so it never belongs in version control. Neither does .env, which holds secrets.

Real-world use #

Every deployment pipeline does the same three steps you just did: create an environment, install from a pinned requirements file, run the app. Day 18 of the VPS track and the Docker track both build on this.

Version pinning is what stops a deployment from breaking because an upstream library released a new version this morning. Teams that pin sleep better.

Newer tools — Poetry, pipenv, uv — solve the same problem with lock files and nicer ergonomics. They are worth learning later, but venv plus pip is universal, needs no extra install, and is what you will find on most servers.

Common mistakes #

• Forgetting to activate the environment, then installing into the system Python by mistake.
• Committing the .venv folder to git. It is large and machine-specific.
• Using pip freeze output without ever reviewing it, so an environment full of leftovers becomes the official requirements.
• Leaving versions unpinned, so a fresh install picks up a breaking release.
• Running sudo pip install. That modifies the system Python and can break operating system tools.

Practice #

Create a new folder, make a virtual environment inside it, activate it, install requests, write a three-line script that fetches a public URL and prints the status code, then freeze your requirements and add a .gitignore. Deactivate and confirm the script fails outside the environment.