Article illustration 1

The Long‑Standing Problem of Dev Dependencies

For years, Python developers have wrestled with where to declare packages that are only needed for development, testing, or documentation. The conventional answer—placing them in optional‑dependencies—meant that every consumer of a library had to sift through a list of optional extras to find the tools they actually needed. This lack of a standard, dedicated section caused confusion in CI pipelines, packaging tools, and even in the eyes of new contributors.

"When I first saw PEP 735, I realized we finally had a clean, documented way to separate dev dependencies from the core package." – Simon Willison

PEP 735: Dependency Groups in pyproject.toml

PEP 735 introduces dependency groups, a new top‑level section in pyproject.toml that allows authors to bundle dependencies under named groups. These groups are intentionally non‑required for the final distribution, so they are ignored when a package is installed for production use.

[project]
name = "my‑package"
version = "0.1.0"

[project.dependency‑groups]
# Core runtime dependencies
runtime = ["requests>=2.25"]
# Optional dependencies for building docs
docs = ["sphinx>=5.0"]
# Development tools
dev = ["pytest>=6.0", "mypy>=0.900"]

The dev group, for example, can be activated with pip install .[dev] or, as uv demonstrates, via the --dev flag.

uv’s Adoption of Dependency Groups

The modern Python resolver uv has already embraced the new standard. When a developer runs uv add --dev the tool automatically places the dependency in the dependency‑groups.dev section. Subsequent uv sync or uv run commands respect this grouping, ensuring that dev tools are available during development but omitted from the final wheel.

$ uv add --dev mypy
# pyproject.toml now contains:
[project.dependency-groups.dev]
myPy = "0.900"

This integration demonstrates how the ecosystem is moving toward a unified approach, reducing friction for both library authors and consumers.

Why It Matters for the Community

  • Reproducibility – CI systems can now pin only the runtime group, guaranteeing that production builds are deterministic.
  • Clarity – New contributors see a clear separation between what is needed to run the code and what is needed to develop it.
  • Tooling Harmony – Package managers and build tools can treat dev groups uniformly, simplifying plugin development.

Simon Willison’s own workflow shows the practical benefits: by declaring dev dependencies in his pyproject.toml, he allows collaborators to fork and run tests with a single command, without pulling in unnecessary packages.

Looking Ahead

With PEP 735 now a PyPA standard, the next steps involve wider adoption by packaging tools, documentation generators, and continuous‑integration services. As the community embraces dependency groups, we can expect a cleaner, more maintainable Python ecosystem where the line between runtime and development code is unmistakably drawn.

Source: https://metaist.com/blog/2025/12/dependency-groups.html