Phase 2: Dev Environments & Dependency Management · ~40 minutes · uv · Python

Virtual Environments and Dependency Management

Two projects, two different versions of the same library, zero conflict — because neither one is actually installed globally. That's the whole trick.

Hiring signal: Never installs a package globally 'just this once,' and can explain exactly what a lock file guarantees

What you will learn

Explain what a virtual environment actually isolates, and what it doesn't
Use uv to create an isolated environment and manage dependencies with a real lock file
Explain why a lock file pins exact versions, not just 'install requirements'
Diagnose the version conflict a shared global environment would cause

Introduction

Type: Learn Languages: Python, uv Prerequisites: Lesson 01 ("Works on My Machine") Time: ~40 minutes

Objective

Learning objectives

Explain what a virtual environment actually isolates, and what it doesn't
Use uv to create an isolated environment and manage dependencies with a real lock file
Explain why a lock file pins exact versions, not just "install requirements"
Diagnose the version conflict a shared global environment would cause

What you're building

Create two separate uv projects, each depending on a different version of the same real package (any package is fine — requests, or another you're familiar with)
Confirm both versions are genuinely installed and correct in each project independently (uv run python3 -c "import X; print(X.__version__)" in each)
In one of the two projects: delete .venv entirely, run uv sync, and confirm the exact same version comes back — this is your reproducibility proof
Write dependency_notes.txt stating both projects' exact locked versions and explaining, using this lesson's mechanism (isolated .venv per project), why installing either package globally "just this once" would have silently reintroduced Lesson 01's implicit-dependency trap

Project X's pyproject.toml lists numpy>=1.24. Project Y's lists numpy==1.24.0 exactly. A teammate runs uv sync on Project X eight months after it was created. What determines the exact numpy version they get?

This is the core distinction this lesson draws between pyproject.toml (the constraint you asked for) and uv.lock (the exact version that was actually resolved and recorded). Even though >=1.24 in pyproject.toml would technically permit a much newer numpy release eight months later, uv sync installs exactly what uv.lock specifies — the version that was resolved and locked at commit time — not a fresh re-resolution against today's available packages. This is precisely the guarantee that makes 'reproducible eight months later' possible at all.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.