How do uv workspaces and named dependency groups work?

Q: How do uv workspaces and named dependency groups work?

**Target Audience:** Developers moving a multi-package Python repo to uv, and candidates asked about Python monorepos and modern packaging **Difficulty:** Medium **Python version:** The in-page examples were run on CPython 3.11 and in this page (Pyodide 0.25.1, CPython 3.11.3). Every uv session below was run with uv 0.11.32 on Linux against python3.11; long `file://` paths are shortened to `file://.../` and the timing in "Resolved N packages in Xms" lines will differ on your machine. > **How to read this doc:** Each idea is explained in plain language first, then tagged with `📌 Interview term:` so you also learn the exact word an interviewer expects. Every output block in the **Verified** section was copied from a real run of the examples on this page. ## 1. Why This Even Matters — A Story First A restaurant group runs three kitchens (the API, the background worker and a shared prep kitchen called "core"). If each kitchen buys its own ingredients from different suppliers on differe

The problem

Question presented to candidate: "Say we have a monorepo with an API service, a worker and a shared core library, all in Python, managed with uv. How would you set it up as a uv workspace, how do the packages depend on each other, and how do you keep test, lint and docs tools out of production installs with dependency groups?"

What a strong answer should cover:

A workspace is a root pyproject.toml with [tool.uv.workspace] members (globs) and optional exclude; every member keeps its own pyproject.toml, but there is one uv.lock and one .venv at the root, so all members agree on every version
Members depend on each other by normal name in [project].dependencies plus { workspace = true } in [tool.uv.sources]; they are installed as editable, and uv errors if the source entry is missing
Commands work on the root by default and target a member with --package (or all with --all-packages); requires-python is the intersection over all members
Dependency groups (PEP 735, [dependency-groups]) are named lists of requirements that are not published in the package metadata, unlike extras in [project.optional-dependencies]; { include-group = "..." } composes them, names are normalised, cycles are errors
uv installs the dev group by default; --no-dev, --group, --only-group, --all-groups and [tool.uv] default-groups change the selection, and [tool.uv] conflicts allows groups that cannot be installed together
Trade-off: one lock means one version of each dependency for the whole repo; members with genuinely incompatible requirements belong in separate projects (or path dependencies)

Clarifying questions expected:

Must every service be deployable and versioned separately, or is it one product?
Do any members need a different version of a shared dependency, or a different Python?
Which tools must be in CI only, and which are needed for local development?

Code / implementation expected: Yes — sketch the root and member pyproject.toml tables and the uv sync / uv run --package commands.

uv
workspaces
monorepo

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Developers moving a multi-package Python repo to uv, and candidates asked about Python monorepos and modern packaging Difficulty: Medium Python version: The in-page examples were run on CPython 3.11 and in this page (Pyodide 0.25.1, CPython 3.11.3). Every uv session below was run with uv 0.11.32 on Linux against python3.11; long file:// paths are shortened to file://.../ and the timing in "Resolved N packages in Xms" lines will differ on your machine.

How to read this doc: Each idea is explained in plain language first, then tagged with 📌 Interview term: so you also learn the exact word an interviewer expects. Every output block in the Verified section was copied from a real run of the examples on this page.

1. Why This Even Matters — A Story First

A restaurant group runs three kitchens (the API, the background worker and a shared prep

The solution is hidden so you can try first

16 min read · 13 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

PythonModel of workspace discovery: members, sources, order, Python range

Practice

PythonModel of dependency groups: include-group, names, cycles, sync flags

Practice

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.