Add uv fix support to the Python package updater

[orto17]

• The pull request is targeting the dev branch.
• The code has been validated to compile successfully by running go vet ./....
• The code has been formatted properly using go fmt ./....
• All static analysis checks passed.
• All tests have passed. If this feature is not already covered by the tests, new tests have been added.
• Updated the Contributing page / ReadMe page / CI Workflow files if needed.
• All changes are detailed at the description. if not already covered at JFrog Documentation, new documentation have been added.

---

Stacks on top of jfrog/jfrog-cli-security#880 (Pip/Uv detection ambiguity fix) — uv is now detected correctly, but there was no fix implementation for it: GetCompatiblePackageUpdater had no case for techutils.Uv, so any fix attempt hit the unsupported-technology path.

Adds a handleUv method to PythonPackageUpdater that rewrites the pinned dependency directly in pyproject.toml — wherever it appears (main dependencies, optional extras, or a PEP 735 dependency-groups table) — then runs uv lock --upgrade-package to refresh uv.lock.

Why not uv add

The obvious approach, mirroring Poetry's handler (poetry add pkg==version + poetry update), doesn't generalize: uv add pkg==version requires an explicit --group/--optional flag to target anything outside the main dependency list, and hard-fails with a resolver conflict if you omit it while the package lives in a dependency-groups table. There's no evidence data available (from Xray or the SBOM) telling us which group a dependency came from, so that flag can never be chosen reliably.

Instead this reuses the same mechanism the existing Pip handler already uses (handlePip): a text substitution of the exact pinned line, regardless of which manifest table it's in, followed by a lock refresh. It's also simpler than Poetry's handler — uv add already keeps pyproject.toml and uv.lock in sync in one command, so the equivalent here is one substitution + one scoped lock refresh, no two-step CLI dance.

Verification

Added test fixtures under tests/testdata/projects/package-managers/uv/ (plain project, indirect-dependency, dependency-groups, and a two-package workspace) and four new subtests in TestUpdateDependency:

Indirect dependency → ErrUnsupportedFix, matching pip/poetry/pipenv.
Plain direct dependency → pyjwt==1.7.1 becomes 2.4.0 in pyproject.toml; uv.lock refreshed.
Dependency-groups ([dependency-groups].dev) → same fix succeeds, no --group flag needed, unlike a naive uv add.
Workspace (dependency owned by a member, not the root) → fails safely with "impacted package not found, fix failed", the same error Pip's handler already returns for an unmatched package; root's pyproject.toml is left untouched.

Limitations

• Workspaces aren't fixed, only safely rejected. If the vulnerable dependency is declared in a workspace member's pyproject.toml rather than the scanned target's own file, this handler can't locate it — it only ever reads/writes the target directory's own manifest. The result is a clean failure (no wrong-file edits, no corruption), not a fix. Solving this needs the vulnerability's evidence to identify which workspace member owns it, which isn't available today.
• Indirect/transitive dependencies are unsupported, same as pip/poetry/pipenv — uv does have a resolver-driven option (uv lock --upgrade-package without editing the manifest first) that pip fundamentally lacks, but that's a possible future enhancement, not attempted here, to keep behavior consistent with the other Python managers.
• Requires the uv binary and network access wherever the fix runs (CI/build environment), same precondition Poetry and Pipenv already have.
• Static, single-pin assumption: like handlePip, this assumes the impacted version is statically pinned with a simple operator (==, >=, etc.) directly in the manifest — it doesn't handle version ranges spanning multiple constraints in unusual ways, dynamic versions, or a dependency declared via path/git/url sources instead of a version pin.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: b679f033-4ad1-4912-908f-7b8ad8393f21

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[Jordanh1996]

From frogbot side - don't forget to whitelist yarn and uv(and dotnet once its ready)