requirements.txt and setup.py projects: dependency claims silently unchecked, or falsely reported missing next to any other manifest

[theyashasvipandey]

The dependency checker reads package.json and pyproject.toml only. A project
that declares its packages in requirements.txt or setup.py gets one of two
outcomes, and which one it gets depends on whether some other manifest happens
to be readable:

project shape	result
requirements.txt alone	no dependency checking at all — silent
requirements.txt + package.json	DEPENDENCY_MISSING for every Python claim
requirements.txt + root pyproject.toml	DEPENDENCY_MISSING for the requirements-declared ones
setup.py + package.json	DEPENDENCY_MISSING for every Python claim
Cargo.toml + package.json	DEPENDENCY_MISSING for every Rust claim

All five reproduced on main.

The first row is the entries.length ? entries : null contract working as
designed — null means "this project's packages can't be read" and suppresses
every dependency issue. That is the right call. The problem is that adding one
readable manifest anywhere flips the checker on and then measures Python claims
against a list that was never going to contain them.

So the failure is not "Python is unsupported"; it is that support is decided by
an unrelated file's presence.

Expected behavior

Either parse these manifests, or keep the checker off for claims belonging to an
ecosystem whose manifest was found but not understood. The second is much
cheaper and removes the false positives on its own.

A warning for whoever implements the parsing half

requirements.txt and setup.py are both harder than they look, and the
existing null contract means a half-parser is worse than no parser:

• requirements.txt supports -r other.txt includes, -e . editable installs,
  VCS and URL requirements (git+https://…#egg=name), environment markers, and
  --hash continuation lines. The name is recoverable from most of these, but
  a file that is mostly -r includes yields almost nothing unless includes are
  followed.
• setup.py is executable Python. install_requires is frequently built from a
  variable, a file read, or a comprehension. Static extraction gets the literal
  case and nothing else, and there is no safe way to get the rest.

If only the literal cases are parsed, those projects end up in the second row of
the table above — switched on and measuring against an incomplete list — which is
the outcome the existing comment in loadAllDependencies warns against. Scoping
this to "recognize the ecosystem, suppress its claims" first is the safer order.

Additional context

#3 (closed by #185) tracked pyproject.toml, Cargo.toml and go.mod; only
pyproject landed. Cargo and go.mod belong with that thread rather than this one —
this issue is specifically about the two Python manifests #3 never covered, and
about the presence-dependent behavior that affects all of them.