[theCodeDrift]

Stack (root → tip):

• ➡️ fix(detect): find Python linters declared as pyproject dev dependencies #574 (you are here)
  • feat(detect): Improve existing linter detection #575

A Python repository that installs ruff as a dev dependency and runs it on its defaults has no [tool.ruff] table, and taskless detect reported it as having no linter. pythonDepsFromPyproject read only [project] dependencies and Poetry.

It now also reads:

• PEP 735 [dependency-groups] (what uv add --dev writes); { include-group } entries are skipped
• [tool.uv] dev-dependencies
• [tool.pdm.dev-dependencies]
• Hatch environment dependencies / extra-dependencies
• Poetry groups through [tool.poetry.group.<name>.dependencies]. Previously the group name was read as a dependency, so dev was recorded and the packages inside were not.

Repos with [tool.ruff] were already detected correctly (checked against fastapi, pydantic, httpx, flask, requests, poetry).

Tests: one case per location, plus a regression for the Poetry group-name read. Patch changeset included.

[theCodeDrift]

@claude /review

[github-actions]

Claude finished @theCodeDrift's task in 2m 2s —— View job

---

Review complete

Review mode: incremental — read 0 prior review thread(s) before reviewing. The .prior-review.json snapshot contained no prior review threads or review bodies (only the trigger comment itself), so this is the first review of this PR — everything below is assessed fresh.

• Read prior review data (none found)
• Fetch PR diff and changed files
• Read full file contents for context (packages/cli/src/detect/scan.ts, packages/cli/test/detect.test.ts)
• Review correctness, security, performance, tests, clarity
• Post inline comments for findings
• Post final summary

Assessment

The change in packages/cli/src/detect/scan.ts (pythonDepsFromPyproject) is correct and well targeted. I checked each new location against the actual tool formats it's meant to represent:

• PEP 735 [dependency-groups] (top-level, not under [tool]) — correctly read; requirementNames filters out non-string entries, so { include-group = "..." } tables are safely skipped rather than crashing or being mis-read as a package name.
• [tool.uv] dev-dependencies — correctly read as a flat PEP 508 array, matching uv's legacy format.
• [tool.pdm.dev-dependencies] — correctly read as a table of named groups, each an array of requirement strings, matching PDM's actual format.
• Hatch [tool.hatch.envs.<name>] — correctly reads both dependencies and extra-dependencies per environment.
• Poetry groups ([tool.poetry.group.<name>.dependencies]) — this is the real fix: previously the group name (e.g. dev) was read via Object.keys(poetry.group), so the actual packages inside were invisible and the group name itself leaked in as a fake dependency. The rewrite now descends one level into each group's dependencies table and reads the real package names.

asRecord's guard against arrays/non-objects means every new lookup degrades to "no match" on malformed/unexpected TOML shapes rather than throwing — consistent with the file's existing graceful-degradation approach for pyproject.toml.

Tests: the it.each block covers one case per new location (uv, PDM, Hatch, PEP 735, Poetry group), plus a dedicated regression test asserting a Poetry group named ruff containing pytest is no longer misread as the linter ruff — directly exercising the bug described in the PR body. I traced each test's TOML against the parsing code and confirmed the expected extraction in all cases.

One minor, non-blocking suggestion (posted inline on scan.ts lines 414–431): the "flatten each named group's requirement array" pattern repeats three times (optional-dependencies, dependency-groups, PDM dev-dependencies). A small shared helper would remove the duplication, but the logic at all three sites is correct as written — purely a readability nit.

No correctness, security, or performance issues found.

[theCodeDrift]

Re: @github-actions — "Claude finished @theCodeDrift's task in 2m 2s — Review complete…"
#574 (comment)

Thanks. The one inline suggestion, the repeated named-group flatten, is fixed in 1d2788b, which adds a shared groupedRequirementNames helper. Nothing else to act on.

— AI Coding Agent