[jdx]

Summary

• add a per-tool registry_url option to the pipx backend
• use the selected registry for version listing, exact-version validation, and latest-version resolution
• key the latest-version cache by registry URL to prevent cross-registry cache reuse
• document private-index usage alongside existing uvx_args and pipx_args

Root cause

uvx_args and pipx_args are install-time options, while latest is resolved earlier through the global pipx.registry_url. A private package could therefore be installed when pinned but could not resolve latest without changing the registry globally.

This adds a discovery-only per-tool override, so other pipx tools continue using PyPI and installation can retain explicit extra-index semantics.

Fixes the limitation reported in #11753.

Validation

• cargo test backend::pipx::tests --all-features
• mise run lint-fix

AI-assisted — Tool: Codex; model: unavailable/unavailable; version: unavailable.

---

Note

Medium Risk
Touches core pipx version-resolution and caching paths; install still relies on global index URL, so misconfiguration could mean resolved versions come from a different index than install unless uvx_args/pipx_args align.

Overview
Adds a per-tool registry_url tool option on the pipx backend so version discovery can target a private PyPI-style index without changing the global pipx.registry_url.

registry_url is read from tool options (overriding settings) and drives remote version listing, latest resolution, and exact-version validation for PyPI packages. remote_version_cache_context and the latest-version cache are keyed by registry URL so two tools with different registries do not share cached version data.

Install-time index behavior is unchanged: uvx_args / pipx_args still control how pip/uv install packages. Documentation in pipx.md describes the new option and how it pairs with those args.

New integration tests use mock HTTP servers to verify per-tool latest resolution and isolated remote-version caches.

^{Reviewed by Cursor Bugbot for commit 78deea6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Summary by CodeRabbit

• New Features

  • Added per-tool package registry URL configuration for pipx-managed tools.
  • Registry URLs can include the package name and override the global registry for version checks.
  • Version lookups support private registries with isolated caching.

• Documentation

  • Added guidance for configuring registry URLs and installation arguments.

[coderabbitai]

📝 Walkthrough

Walkthrough

The pipx backend now supports per-tool registry_url options. It resolves the effective URL asynchronously for version discovery and validation, partitions caches by registry URL, and documents the option with a private registry example.

Changes

Pipx registry configuration

Layer / File(s)	Summary
Registry option resolution src/backend/pipx.rs, docs/dev-tools/backends/pipx.md	Pipx reads a per-tool registry_url, falls back to the global registry setting, and documents the required package-name placeholder. Version discovery and exact-version validation use the resolved URL.
Registry-aware version lookup and caching src/backend/pipx.rs	Remote and stable-version lookup use the selected registry. Latest-version cache paths include a hash of the registry URL.
Private registry validation src/backend/pipx.rs	Tests resolve packages from a private JSON registry and verify cache isolation across registry URLs.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Sequence Diagram(s)

sequenceDiagram
  participant ToolConfiguration
  participant PIPXBackend
  participant RegistryCache
  participant PackageRegistry
  ToolConfiguration->>PIPXBackend: provide per-tool registry_url
  PIPXBackend->>ToolConfiguration: resolve effective registry URL
  PIPXBackend->>RegistryCache: select registry-specific cache
  PIPXBackend->>PackageRegistry: request package versions
  PackageRegistry-->>PIPXBackend: return available versions

Loading

Possibly related PRs

• jdx/mise#11147: Both changes add per-tool registry-aware version resolution and isolated registry configuration.
• jdx/mise#11457: Both changes modify src/backend/pipx.rs, including version-filtering interfaces.

Suggested reviewers: risu729, jambalaya56562

Poem

I’m a rabbit guarding each registry URL,
Pipx checks versions and caches them well.
Private indexes answer the call,
Separate caches keep results tall.
Hop by hop, the tests confirm it all.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely identifies the main change: adding per-tool registry URL support to the pipx backend.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 56a3a7a. Configure here.}

[greptile-apps]

Greptile Summary

The PR adds a per-tool pipx registry URL for version discovery and isolates cached version results by effective registry.

• Resolves version lists, exact-version validation, and latest against the selected registry.
• Separates both remote-version and latest-version caches across registry URLs.
• Documents private-registry configuration while keeping installation index arguments separate.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the previously reported registry-blind remote-version cache is now partitioned by registry context in memory and on disk, with dedicated two-registry coverage.

Important Files Changed

Filename	Overview
src/backend/pipx.rs	Adds per-tool registry selection and correctly partitions remote and latest-version caches by the effective registry URL, resolving the previously reported cache collision.
docs/dev-tools/backends/pipx.md	Documents the discovery-only registry override and the separate installation index arguments.

_{Reviews (2): Last reviewed commit: "fix(pipx): isolate remote version cache ..." | Re-trigger Greptile}

[coderabbitai]

🧹 Nitpick comments (1)

src/backend/pipx.rs (1)

1043-1111: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add latest-version cache-isolation coverage.

This test validates list_remote_versions, but it does not validate the separate cache used by latest_stable_version. Add a two-registry test that calls latest_stable_version on both backends and asserts 1.0.0 and 2.0.0. This will detect a registry-hash collision or omitted registry key in the latest-version cache.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/backend/pipx.rs` around lines 1043 - 1111, Extend the
per_tool_registries_isolate_remote_version_cache test to also call
latest_stable_version for both configured backends and assert the
registry-specific results are 1.0.0 and 2.0.0. Keep the separate mock registries
and existing list_remote_versions assertions so the latest-version cache
includes the registry identity and cannot reuse the other backend’s value.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/backend/pipx.rs`:
- Around line 1043-1111: Extend the
per_tool_registries_isolate_remote_version_cache test to also call
latest_stable_version for both configured backends and assert the
registry-specific results are 1.0.0 and 2.0.0. Keep the separate mock registries
and existing list_remote_versions assertions so the latest-version cache
includes the registry identity and cannot reuse the other backend’s value.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: 1f918afd-5a0d-49d5-b526-ad6d352ee2c8

📥 Commits

Reviewing files that changed from the base of the PR and between 56a3a7a and 78deea6.

📒 Files selected for processing (1)

• src/backend/pipx.rs

[github-actions]

Instruction counts

Nothing was compared, and so nothing was gated. No series appears on both sides: either the base has no measurements recorded, or the two were measured on different runner classes, which are deliberately not comparable — counts shift between machine types by more than a real regression does.

New, nothing to compare against: env on bamboo-v2-ubuntu24.04-x64-30vcpu-24gb-rust1.97.1, hook-env on bamboo-v2-ubuntu24.04-x64-30vcpu-24gb-rust1.97.1, ls on bamboo-v2-ubuntu24.04-x64-30vcpu-24gb-rust1.97.1, registry on bamboo-v2-ubuntu24.04-x64-30vcpu-24gb-rust1.97.1, startup on bamboo-v2-ubuntu24.04-x64-30vcpu-24gb-rust1.97.1

_{Only instruction counts gate. Wall clock is shown for context — on identical hardware it moves 4-20% run to run.}

_{Measured by tak — instruction-counted CLI benchmarks, stored in this repository's git notes.}

_{78deea6c2072 vs 622895c9dabc · measured on the runner, not pushed to the history.}