fix(uv): prefer uv.lock versions in parser output

[Nishnha]

What are you trying to accomplish?

Fix the underlying bug from #14954 (which I had to roll back because it broke the file updater). Credit to @jmcgrath-tractian for the original report and fixture.

When both uv.lock and a requirements.txt / .in file list the same package, Dependabot::Uv::FileParser#parse previously returned the requirements.txt version. DependencySet#combined_version prefers the entry whose top_level? is true, and uv.lock entries always have empty requirements: [], so the requirements.txt entry wins — even when it is stale.

Result: the dependency graph reports the stale version, and Dependabot security alerts don't auto-dismiss after uv lock has already shipped the patched version.

What changed

Follows @v-HaripriyaC's suggestion on #14954 to move the fix out of "skip the requirements parser entirely" and into dependency selection:

• Build the full dependency set as before (pyproject + uv.lock + requirements.*)
• Then post-process it: any package that also appears in uv.lock takes the lockfile-resolved version, while keeping the requirements collected from other files
• Lift uv.lock parsing into a dedicated FileParser::LockFileDependencyParser helper

Net effect:

• The dependency graph gets the correct uv.lock version
• The FileUpdater still sees the requirements.txt entry in dep.requirements, so it can update those files when needed — no spike in Expected lockfile to change! from LockFileUpdater#fetch_updated_dependency_files
• Packages that appear only in requirements.txt (no uv.lock entry) are unaffected

Tests

Three new specs in uv/spec/dependabot/uv/file_parser_spec.rb:

• stale requirements.txt + uv.lock → parser returns the uv.lock version
• same scenario → requirements.txt is still listed in the dep's requirements (so the file updater path still works)
• package only in requirements.txt (not in uv.lock) → still parsed normally

Verified all 70 file_parser_spec examples plus dependency_grapher_spec and file_updater_spec pass. The one workspace-member failure that shows up is pre-existing on main.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[Copilot]

Pull request overview

This PR fixes uv dependency parsing so resolved versions from uv.lock are preferred over stale versions from requirements files while preserving requirements metadata for file updates.

Changes:

• Adds a nested LockFileDependencyParser helper for parsing uv.lock.
• Post-processes parsed dependencies to replace versions with lockfile-resolved versions when available.
• Adds specs covering stale requirements files and requirements-only packages.

Show a summary per file

File	Description
uv/lib/dependabot/uv/file_parser.rb	Wires in the lockfile parser and applies lockfile version preference after building the full dependency set.
uv/lib/dependabot/uv/file_parser/lock_file_dependency_parser.rb	Adds uv.lock parsing and dependency version preference logic.
uv/spec/dependabot/uv/file_parser_spec.rb	Adds regression coverage for stale requirements versions and requirements preservation.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0

[brrygrdn]

Nice, this makes sense to me from a dependency graphing perspective. Because it affects updates as well I'll hold off on giving a formal ✅ as it's probably worth a second pair of eyes

[jakecoffman]

Wait, why is the uv ecosystem fetching and parsing requirements.txt and .in files?

[Nishnha]

Wait, why is the uv ecosystem fetching and parsing requirements.txt and .in files?

Yeah good question - customers can have both in their repo and uv lets you export lockfiles to requirements.txt https://docs.astral.sh/uv/concepts/projects/export/#requirementstxt-format

But we can also go the route of ignoring requirements.txt for uv graph jobs. I'll take a look at that option.