Support PEP 735

[mjspeck]

Is your feature request related to a problem? Please describe.

Right now, Deptry looks for [project.optional-dependencies] in pyproject.toml, but not for [dependency-groups] which was added in PEP 735. This makes it erroneously classify any dependencies listed there as transitive.

Describe the solution you would like

Look for both [project.optional-dependencies] and [depdency-groups] for dependencies. In theory, [project.optional-dependencies] should only have runtime dependencies, while [dependecy-groups] should have building, testing, linting, etc. dependencies, so a more advanced solution would allow deptry to only check those dependencies against certain files (like the tests folder, for example).

Additional context

[dsully]

Supporting PEP-735 would be greatly appreciated. It's first class in uv and is seeing a lot of use.

Thanks

[CAprogs]

This pull request mention the support of PEP 735 but the actual documentation state that uv is detected as the package manager when it uses the PEP 621

[mkniewallner]

deptry does support PEP 735, but it intentionally flags the dependencies found in [dependency-groups] as development dependencies (since it's mostly the intent behind PEP 735).

But technically, on a project that is not meant to be installed (i.e., not a package you build and use in another project), I guess you could somehow use dependency groups as "production" dependencies groups.

Is this a use case that some of you have, and if so, can you share an example? Because I intentionally left that out in #892 at the time, since I wasn't sure if this was a real use case, but I'd be willing to add a parameter to make that configurable if this is a real use case (similarly to pep621_dev_dependency_groups that was really useful before PEP 735 was introduced).

[coreyjadams]

Hi @mkniewallner - not my issue, but I found it looking for this functionality.

I'm working on a big OSS project where we're trying to be very careful about our dependency creep. It's become a major headache for installation for our users. I was looking at dependency-groups from PEP 735 for exactly this reason. For example, if the pacakge structure is

package
├── __init__.py
├── subfolderA
|   ├── __init__.py
|   └── fileA.py # imports externalPackage1
└── subfolderB
    ├── __init__.py # imports subfolderA
    └── fileA.py # imports externalPackage2

Then, if we want to enforce no new dependecies are added, we might have a dependency group tree like so:

[dependency-groups]
subfolderA = [
    "externalPackage1>=1.2.3",
]
subfolderB = [
    "externalPackage2>=3.2.1",
    {include-group = "subfolderA"}
]

[tool.uv]
no-build-isolation-package = ["torch_scatter"]
managed = true
default-groups = ["subfolderB"] # Or "all" in this very simple case.

I am imagining a CI scenario where we would run:

deptry package/subfolderA --group subfolderA
deptry package/subfolderB --group subfolderB

Etc, manually. This would catch PRs that start adding extra dependencies, which is a scenario we do actually need to track... it's not obvious in this very simple example. This project has a model hub area and examples area that can start getting unexpectedly complex in terms of dependencies. So we're leaning into being more strict on chasing dependencies.

Is this a feasible use case for deptry?