Why did PEP 735 add dependency groups when pyproject.toml already had extras?

### The gap extras left Before PEP 735 there were exactly two standard-ish places to write down "the packages I need to *work on* this project": a `requirements-dev.txt` file, which is a pip-specific convention with no metadata standard behind it, or an extra named `dev`, `test` or `lint`. Both were compromises, and the extra was the worse one for four concrete reasons. **An extra is published metadata.** Everything under `[project.optional-dependencies]` is compiled into the wheel's `METADATA` as `Provides-Extra` and marker-guarded `Requires-Dist` lines. Your test runner, your type checker and your coverage plugin therefore appear on the index page of a library that has nothing to do with them, and any consumer can install them with `pip install yourlib[dev]`. They also enter the dependency graph of your distribution, so their version constraints can participate in a downstream resolution that has no business seeing them. **An extra requires you to be a package.** Extras live inside the `[project]` table, which is build-backend metadata. A repository that is an application, a service or a batch pipeline — no wheel, no publication, nothing importable by anyone else — had no legitimate way to declare its development requirements in `pyproject.toml` at all. It had to invent a build backend just to get a place to write them down. **Installing an extra installs your project.** `pip install -e ".[dev]"` builds and installs your own distribution as a side effect of fetching a linter. In CI that is wasted work at best, and at worst it fails for an unrelated reason (a missing compiler, a build backend that cannot run on the image) when all you wanted was the tools. **Extras cannot be composed.** There is a self-referential trick (`all = ["mypkg[test,lint]"]`) but it only works because the project is installable, and it drags the project install along with it. ### What a dependency group is PEP 735 defines a **top level** table — note that it is *not* nested under `[project]`: ```toml [dependency-groups] test = ["a-test-runner>=8"] lint = ["a-style-checker", "a-type-checker"] dev = [{include-group = "test"}, {include-group = "lint"}, "a-debugger"] ``` Each key is a group name (normalized like a package name), and each value is a list whose entries are either requirement strings or inline tables of the form `{include-group = "other"}`. Inclusion is how groups compose: `dev` above expands to the union of `test`, `lint` and its own entries, with cycles forbidden. The defining property is scope. A dependency group is **source-tree metadata**. It is not copied into the wheel or the sdist's built metadata, no consumer can install it from the index, and it does not participate in the resolution of your distribution for anyone else. It also does not require a `[project]` table or a `[build-system]` table: a `pyproject.toml` containing nothing but `[dependency-groups]` is valid and useful, which is what finally gave non-package repositories a standard home for their tooling. ### Installing them pip gained `--group` in version 25.1 (2025): `python -m pip install --group dev` reads `pyproject.toml` in the current directory and installs that group; the longer form `--group path/to/pyproject.toml:dev` points elsewhere. Other installers read the same table natively — uv resolves groups as part of its project workflow and treats `dev` specially. An installer that predates the PEP simply never looks at the table. ### What they are not A dependency group is **not a lockfile**. It holds requirement specifiers, exactly like `[project] dependencies` does, and it is resolved fresh at install time; reproducible installs are still the job of a lock or constraint mechanism. It is also not a replacement for extras. The two answer different questions. An extra says *"consumers of this library may opt into this feature"* and is therefore public and published. A group says *"people working in this checkout need these tools"* and is therefore private and local. The decision rule is simply: if someone installing your package from an index would ever want it, it is an extra; if it only makes sense inside the repository, it is a group. ### The migration Moving from a `dev` extra to a `dev` group is mostly mechanical — copy the list, drop the `-e .` self-install if your test command does not actually need the package importable, and update CI. The one thing to check is anything that relied on the dev extra being installable from the index, because that capability is deliberately gone.