PEP 735: Dependency Groups in pyproject.toml

Packaging Standards
199

I like that you are aiming to keep these dependencies static. To enforce this, you could add a requirement that tools supporting dependency groups must raise an error when a reference to a dynamic dependency is made. That is a straightforward requirement and should be preferred over extending project.dependencies in a way that yields substantial adoption and backwards compatibility issues I think. There is no fundamental problem with keeping this inside the design for dependency groups, so talking about versioning of the [project] table is going down the wrong path.

Other issues with the current proposal beyond what @EpicWink mentioned include:

  • It is very well possible that one wants to include optional dependencies or build dependencies in a particular dependency group (e.g., a dev group probably needs the build dependencies installed). If you want to be able to refer to another list of dependencies, you should aim to support all such lists that exist today imho.
    • We’ve learned this lesson before, e.g. for overriding constraints IIRC there’s still an asymmetry in Pip’s UX where runtime deps can be overridden more easily than build deps, and that can be painfully difficult to work around.
    • This is easier to do when including it in dependency groups, rather than also updating the semantics of those other existing metadata fields.
  • If you change project.dependencies, it is likely to affect other designs. E.g., PEP 725 is making a symmetric introducing of external.dependencies: pep-0725/#dependencies-optional-dependencies. We shouldn’t have to worry about dependency groups there.
  • The “layering” of the design seems conceptually wrong the way you want to do it. Build and runtime dependencies are more central to a package, and are (as you point out) user-facing.
    • A common way of finding a package’s dependencies is to look at its pyproject.toml (it’s 2-3 clicks: go to PyPI, click the Source link, open pyproject.toml in your browser). Most other methods, like pipdeptree, require installing the package first. So now that user-facing metadata is moved to a more private location with extra mental overhead.