`uv`/Python private registry packages need package-level registry authority during update selection

Is there an existing issue for this?

• I have searched the existing issues

Feature description

Dependabot appears to mix public version discovery with private-index resolution for Python/uv projects when the same package name exists on both a private index and public PyPI.

This creates a failure mode where Dependabot selects the latest public version of a package, but uv later refuses to resolve it because the package is present on a private index first and uv treats that private index as authoritative for that package.

Example scenario

Suppose a project depends on package acme-compiler.

Versions available:

• Private index: 0.8.3, 0.8.4
• Public PyPI: 1.1.1

The project intends acme-compiler to come from the private index only.

Dependabot attempts to update to 1.1.1, but uv then fails because:

• it finds acme-compiler on the private index first
• it does not consider public PyPI versions for that package after that
• 1.1.1 is not available on the private index

Why this is a problem

The issue is not in uv resolution. The resolver is behaving correctly and safely.

The problem is that Dependabot’s candidate selection appears not to be constrained by the same package-to-registry authority that uv uses during resolution.

That means:

• update discovery points at the public version stream
• resolution later enforces the private version stream
• the update fails instead of selecting the next valid private version

What we expected

Dependabot should either:

• select the next version available on the authoritative private index (0.8.4 in the example), or
• honor package-level source/registry rules during version discovery so that public-only versions are never proposed for that package

What would help

Any of the following would address this:

1. Respect package-level source metadata such as tool.uv.sources during version discovery.
2. Add a per-package “private registry only” rule in dependabot.yml.
3. Allow a private registry to be authoritative for a subset of package names while leaving public PyPI available for unrelated packages.
4. Ensure Dependabot’s version discovery and final uv resolution use the same effective index semantics.

Why existing config is not enough

• Putting the private index first is not sufficient if version discovery still considers public versions.
• replaces-base: true is too coarse for mixed environments that still need PyPI for unrelated packages.
• The missing capability is package-level registry authority, not ecosystem-wide registry replacement.

Related context

The uv docs explicitly document private-first / first-index behavior to avoid dependency confusion:

• https://docs.astral.sh/uv/concepts/indexes/
• https://docs.astral.sh/uv/guides/integration/dependency-bots/

Dependabot docs document private registries and replaces-base: true, but there does not appear to be a package-level equivalent:

• https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference

Related issues:

• #7680
• #12087
• #12753

No source files or tests are named. Start by tracing Python/uv version discovery and final resolution, then read the linked uv index documentation and Dependabot private-registry options. Done means package-level registry authority is shared by discovery and resolution, so a private-only package selects its latest private version without blocking unrelated PyPI packages.