Add support for the uv package manager as a Python dependency manager

[wkl3nk]

Description

With the rapid adoption of uv — a modern, high-performance Python package and project manager — it would be valuable for OSS Review Toolkit (ORT) to include native support for analyzing and resolving dependencies from projects managed by uv.

uv is emerging as a successor to traditional Python tools like pip, pip-tools, and virtualenv. It provides a unified workflow for Python dependency management, with full support for pyproject.toml manifests and lock files, but introduces its own resolution logic and file structures.

Motivation and Context

Many modern Python and AI-focused backends (especially in the agentic AI / automation ecosystem) are adopting uv due to its speed, deterministic builds, and ease of integration in reproducible environments.

As a result, more open-source projects analyzed by ORT will be built with uv, and the current Python package managers in ORT (Pip, Poetry, etc.) may not recognize or properly parse uv-specific lock files and metadata.

Adding uv support will allow ORT to:

• Correctly resolve and report dependencies from uv projects
• Improve analysis coverage for modern Python ecosystems
• Maintain ORT’s position as a comprehensive and up-to-date open-source compliance and SBOM tool

Proposed Solution

Add a new Uv package manager implementation to ORT’s analyzers, similar to the existing Poetry or Pip implementations.

Suggested behavior

• Detect presence of uv.lock, pyproject.toml, or .uv project metadata as indicators
• Parse uv.lock to extract dependency graph and versions
• Leverage uv’s CLI or internal lockfile format (JSON-based) for reproducible dependency extraction
• Maintain compatibility with Python ecosystem conventions (PyPI as the main registry, environment markers, etc.)

CLI compatibility

uv already provides commands like:

uv export --format requirements.txt
uv export --format json

## Possible Alternatives

* Use `uv export` to produce `requirements.txt` files and rely on the existing `Pip` analyzer (workaround, but loses fidelity and metadata)  
* Encourage manual preprocessing in CI/CD to normalize `uv` projects before ORT scanning — not ideal for automation or reproducibility

## Additional Context / References

* Official site: [https://astral.sh/uv](https://astral.sh/uv)  
* Documentation: [https://docs.astral.sh/uv](https://docs.astral.sh/uv)  
* Example lockfile structure: [https://docs.astral.sh/uv/guides/lockfiles](https://docs.astral.sh/uv/guides/lockfiles)  
* Example use in modern Python and agentic AI frameworks: [Astral Blog: uv – a faster, unified Python toolchain](https://astral.sh/blog/uv)

[sschuberth]

Did you see #10020, @wkl3nk?

[sschuberth]

Also, please see this comment, which refers to PDM mainly, but the new pylock.toml file format is supposed to be used by UV, too. So we should consider to generically support projects using a pylock.toml, independent of the actual package manager used.

[sschuberth]

Also somewhat related to "lockfile-only analyzers" is this issue.