Monorepos are one of those topics that makes engineers very opinionated, very fast. Google does it. Amazon doesn’t. Your last team swore by them. Your current team swears at them. So who’s right?

This workshop starts with the controversy, because it’s a real one. We’ll trace how monorepos evolved, and what the actual tradeoffs are when you’re a team of two versus a team of 20. No dogma, just honest tradeoffs.

Then we get to work.

Because the inconvenient truth about monorepos in Python is that they were genuinely painful to manage — until recently. Multiple virtual environments drifting apart, dependency conflicts you only discovered in production, Docker builds that copied half your codebase into the image. The tooling just wasn’t there.

uv changed that.

In the second half of this workshop, we’ll use uv workspaces to build a monorepo from scratch: a shared package, two services with their own dependency trees, a unified lockfile, and a quality gate that catches dependency issues before they ship. We’ll see how a single resolved dependency graph surfaces conflicts you didn’t know you had, and how that same graph can produce lean, auditable Docker images.

You’ll leave with a working setup and a clear mental model for when a monorepo is the right call, and how to make it one you’ll still enjoy maintaining six months from now.

Bring a laptop with Python and uv installed. All skill levels welcome; intermediate Python assumed.