Retrieve development dependencies from all dependencies groups in Poetry

[mkniewallner]

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

On projects using Poetry, only [tool.poetry.dev-dependencies] and [tool.poetry.group.dev.dependencies] are considered for retrieving development dependencies.

Since groups only work locally, it is probably safe to assume that dependencies in all groups are development dependencies, regarding of the group. This would also be in line with what we do for PDM, where all dependencies groups are parsed.

Describe the solution you would like

Instead of just parsing [tool.poetry.dev-dependencies] and [tool.poetry.group.dev.dependencies], deptry should parse [tool.poetry.dev-dependencies] and all [tool.poetry.group.<group>.dependencies] to retrieve development dependencies.

Additional context

There might be reasons for users to opt-out from reading dependencies from specific groups (for instance, a specific group that defines dependencies only used by a CI workflow), but we could consider implementing that only if this is a feature that is requested by users.

[jc-louis]

@mkniewallner I think this a mistake, poetry groups are not used only locally (we use them to group per apps in a monorepo), so they are not dev dependencies in all cases.

[mkniewallner]

@mkniewallner I think this a mistake, poetry groups are not used only locally (we use them to group per apps in a monorepo), so they are not dev dependencies in all cases.

Indeed, I must say that I've never used Poetry for mono repositories, so I did not have this use case in mind.

Would a new option similar to https://deptry.com/usage/#pep-621-dev-dependency-groups, but specific to Poetry, would work? By default, we could keep the behaviour as it is today (i.e. all groups are considered as dev depencenies), but if the user specifies a value, then they'll be able to explicitly specify which groups should be considered as dev ones.

[maciejb]

@mkniewallner I have a similar use case, using poetry groups to define a few different execution environments with overlapping dependencies. An option similar to pep-621 but for Poetry would work perfectly in my case.