Layer 8 Session 47 — Gate Beyond the Fundamentals

Packaging & Virtual Environments

The final session. Every pip install across this curriculum quietly assumed a working Python setup. This session covers the practical piece every real project needs: isolating dependencies per-project.

An isolated, reproducible set of dependencies, per project.

Estimated time: 35–40 minutes · Pre-quiz → Concept → Lab → Commit → Post-quiz

1. Learning Objective

By the end of this session you will be able to:

Explain what problem a virtual environment solves
Create and activate a virtual environment with venv
Install packages into an isolated environment and freeze them to a requirements.txt
Recreate an identical environment on a different machine from requirements.txt
Explain, at a high level, what pyproject.toml is for in a real distributable package

2. Pre-Coding Quiz

Answer these before reading the concept explanation or writing any code. It is fine to get these wrong — that is the point. You need 4/5 to proceed to the lab.

Question 1 of 5

Two different projects on the same computer need different, conflicting versions of the requests library. What problem does this create if both use the same global Python installation?

There is no problem — pip automatically keeps versions separate per project Installing one version for one project would silently break the other project, which needs a different version — they cannot both be installed globally at once Python refuses to run any project that has a version conflict anywhere on the machine This can only happen with more than 10 dependencies

A global Python installation has exactly ONE set of installed packages, shared by everything on that machine. Two projects needing different versions of the same library genuinely conflict — this is exactly the problem virtual environments solve.

Question 2 of 5

What does a virtual environment (created with python -m venv env) actually provide?

A separate, isolated copy of the Python interpreter and its own installed packages, independent of the global installation and independent of any other project's environment A faster version of Python A cloud-hosted Python runtime A way to run Python 2 and Python 3 code in the same file

A virtual environment is a self-contained directory holding its own Python interpreter (or a link to one) and its own site-packages — installing something into it has zero effect on the global installation or any other project's environment.

Question 3 of 5

What does pip freeze > requirements.txt do, and why does the whole curriculum's pip install pytest requests (Sessions 32, 42) become more reproducible because of it?

It deletes all currently installed packages It writes every currently installed package and its exact version to a file, so anyone (including future you, on a different machine) can recreate the identical environment with one command It permanently locks the Python version itself It uploads your code to PyPI

requirements.txt is a plain list of package==version pairs. Anyone who clones the project can run pip install -r requirements.txt and get the exact same dependency versions you had — without requirements.txt, "pip install pytest requests" (as taught in earlier sessions) gets whatever the LATEST versions happen to be at install time, which may differ machine to machine.

Question 4 of 5

You clone the Country Explorer project on a new machine and want the exact same dependencies. What is the correct sequence, given a requirements.txt already exists?

python -m venv env, activate it, then pip install -r requirements.txt pip install -r requirements.txt directly into the global Python installation, skipping venv entirely Copy the old machine's venv folder directly onto the new machine and run it requirements.txt does the whole setup automatically with no other commands needed

Create a fresh, isolated virtual environment first, activate it (so pip installs INTO it, not globally), then install from the requirements file. This is the standard, portable Python project setup sequence.

Question 5 of 5

At a high level, what is pyproject.toml for, as opposed to requirements.txt?

They are two names for the exact same file with no real difference requirements.txt lists dependencies for reproducing an environment; pyproject.toml describes a project as a distributable PACKAGE — its name, version, dependencies, and build configuration, for publishing or installing it as a library pyproject.toml is only used by Python 2 projects requirements.txt is required; pyproject.toml is never used in real projects

requirements.txt is about reproducing a working ENVIRONMENT for running a project. pyproject.toml is about describing a project as an installable, distributable PACKAGE — the modern standard for anything meant to be published (e.g. to PyPI) or installed via pip install your-package-name.

3. The Concept — Isolating and Sharing a Python Project

Each project gets its own isolated interpreter and packages — no more conflicts between projects sharing one global Python.

The problem: one global Python, many conflicting needs

Every pip install across this curriculum (Session 32's pytest, Session 42's requests) quietly assumed a single, shared Python installation. In reality, different projects often need different, conflicting versions of the same package — impossible to satisfy with one global set of installed packages.

Creating and activating a virtual environment

venv, built into Python, creates a self-contained directory with its own interpreter and package list — completely isolated from the global installation and from any other project's environment.

# Create a virtual environment in a folder called "env"
# python -m venv env

# Activate it (varies by OS)
# macOS/Linux: source env/bin/activate
# Windows:     env\Scripts\activate

# Once activated, your prompt shows (env) — pip now installs HERE, not globally
# pip install pytest requests

# Deactivate when done
# deactivate

Freezing and restoring dependencies

pip freeze lists every installed package and its exact version. Saving that to requirements.txt lets anyone recreate an identical environment — turning "it works on my machine" into "run these two commands and it works on yours too."

# Inside an activated venv, after installing what you need:
# pip freeze > requirements.txt

# requirements.txt now looks something like:
# pytest==8.3.4
# requests==2.32.3

# On a fresh machine, to reproduce the exact same environment:
# python -m venv env
# source env/bin/activate   (or env\Scripts\activate on Windows)
# pip install -r requirements.txt

pyproject.toml — describing a distributable package

requirements.txt reproduces an environment for RUNNING a project. pyproject.toml is the modern standard for describing a project as an installable PACKAGE — its name, version, and dependencies — used when you want something installable via pip install your-package-name, not just runnable locally.

# pyproject.toml — a minimal example, for context only (not built in this lab)
# [project]
# name = "country-explorer"
# version = "1.0.0"
# dependencies = [
#     "requests>=2.32",
# ]

The curriculum, complete: This is the final session of Python Fundamentals, core and bonus layers alike. You now have the language fundamentals, the object-oriented and testing discipline, the architectural judgment, and the practical project-setup knowledge to build and share a real Python project.

4. Lab

Lab objective: Create a virtual environment for the Country Explorer project, install its real dependencies, and produce a requirements.txt that could recreate the setup on any machine.

What you will build

A virtual environment and a requirements.txt file.

Step-by-step instructions

Create a virtual environment for the project

Run this in your project's root folder.

# python -m venv env

Activate it and confirm you are inside it

Your terminal prompt should now show (env) at the start.

# source env/bin/activate     (macOS/Linux)
# env\Scripts\activate          (Windows)

Install the project's real dependencies

These are the two packages this whole curriculum actually used, in Sessions 32 and 42.

# pip install pytest requests

Freeze the exact versions to requirements.txt

# pip freeze > requirements.txt
# cat requirements.txt   (or open it in an editor)

Simulate a fresh machine: deactivate, then reproduce the environment from scratch

Delete the env folder, then rebuild it purely from requirements.txt, proving the file is sufficient on its own.

# deactivate
# rm -rf env                       (macOS/Linux)   or   rmdir /s env   (Windows)
# python -m venv env
# source env/bin/activate            (or env\Scripts\activate)
# pip install -r requirements.txt
# pip list                            # confirm pytest and requests are both back

5. Expected Files Changed

File	Action	Why
`env/`	Created	An isolated virtual environment for this project (not committed to git).
`requirements.txt`	Created	The exact, reproducible list of the project's dependencies.
`docs/sessions/session-47/index.html`	Created	This session document — the final session of the curriculum.

If you find yourself editing any other file, stop. This session touches exactly 3 files.

6. Commit Checkpoint

Once the lab is complete and you can explain every line, make this exact commit:

git add requirements.txt docs/sessions/session-47/index.html
git commit -m "session-47: isolate dependencies with venv and freeze them to requirements.txt"

Do not commit until you can answer out loud: "Why does the env/ folder itself get excluded from git (via .gitignore), while requirements.txt does get committed?"

7. Code Review Checklist

Go through your code line by line and check each item:

A virtual environment was created and successfully activated

pytest and requests were installed inside the venv, not globally

requirements.txt was generated with pip freeze and contains exact pinned versions

The environment was deleted and successfully rebuilt from requirements.txt alone, proving reproducibility

env/ is excluded from version control via .gitignore; requirements.txt is not

I can explain every line without looking at the concept section

8. Post-Coding Quiz

Same 5 questions. Take it again now that you have written and run the code. You need 4/5 to mark this session complete.

Question 1 of 5

Two different projects on the same computer need different, conflicting versions of the requests library. What problem does this create if both use the same global Python installation?

Question 2 of 5

What does a virtual environment (created with python -m venv env) actually provide?

Question 3 of 5

What does pip freeze > requirements.txt do, and why does the whole curriculum's pip install pytest requests (Sessions 32, 42) become more reproducible because of it?

Question 4 of 5

You clone the Country Explorer project on a new machine and want the exact same dependencies. What is the correct sequence, given a requirements.txt already exists?

Question 5 of 5

At a high level, what is pyproject.toml for, as opposed to requirements.txt?

9. Reflection Questions

Think through these after the post-quiz. No right answer — they are for discussion.

Why should the env/ folder itself never be committed to git, while requirements.txt should be? What is the difference in what each one represents?
What would have gone wrong across Sessions 32-44 if two different learners' machines had silently different installed versions of pytest or requests?
When would you actually need a full pyproject.toml instead of just a requirements.txt? Think about the difference between "running a project" and "publishing a package."
Looking back across all 47 sessions, which single practice from this curriculum do you think will matter most the next time you start a brand-new Python project from scratch?

10. What Breaks If This Knowledge Is Missing?

"Works on my machine" bugs: Without virtual environments and requirements.txt, a project silently depends on whatever happens to be globally installed on one specific machine — the single most common reason a project runs for its author but fails for anyone else.
Dependency conflicts between projects: Without isolation, working on two Python projects with different version needs on the same machine eventually forces you to break one to fix the other — venv is what prevents this entirely.

11. What We Learned

Python concept mastered: Isolating project dependencies with venv, reproducing environments with pip freeze / requirements.txt, and the distinction between an environment file and a distributable package's pyproject.toml.

Unlocks: You can now set up, isolate, and share any real Python project so it runs identically on any machine — the last practical skill standing between "a script that works for me" and a genuinely shareable project.

This is the final session. The curriculum, core and bonus layers alike, is complete.