ERROR: Could not find a version that satisfies the requirement when migrating indexes with overlapping package names

Deterministic resolution without pre‑mirroring

Use a single index at a time or an explicit merge proxy that gives the legacy index higher priority.

Recommended flag combination

1. When the legacy index is still needed as fallback, run pip with only --index-url pointing to the legacy index and --extra-index-url pointing to the new private index only after you have verified that the new index contains every required version.
2. If you cannot tolerate any overlap, run pip with --index-url set to the new index and omit --extra-index-url entirely; keep the legacy index available only for emergency rollback.
3. For environments that must query both indexes simultaneously, place a local proxy (e.g., devpi, Artifactory, or a simple nginx reverse‑proxy) in front of the two sources and configure the proxy to return packages from the legacy index first, falling back to the new index. Then invoke pip with a single --index-url pointing at the proxy.

Why this works

The pip resolver does not guarantee that --index-url outranks --extra-index-url for overlapping names across versions 20.3‑24.x. By eliminating the simultaneous use of both flags (or by enforcing priority via a proxy) the resolver’s search order becomes deterministic, preventing it from picking a version from one index that fails a version specifier while a satisfying version exists in the other.

PEP 708 metadata injection

Current public knowledge does not confirm that bandersnatch or any widely used mirroring tool can rewrite repository metadata to include PEP 708 repository fields, nor that pip versions in the 20.3‑24.x range enforce those fields for source priority. Until a specific tooling version is verified to read and act on PEP 708 metadata, treat it as unavailable for enforcing index preference.

Rolling‑deployment sequence to avoid the error

1. Validate the new index: for every pinned requirement (exact version or hash‑constrained spec) run pip download --index-url == and ensure the artifact is retrieved.
2. Deploy a batch of instances with pip configured to use the new index only (single --index-url) while keeping the legacy index available as a fallback via environment‑level proxy or by not removing it until the batch passes health checks.
3. Monitor the batch; if any installation fails, roll back the batch and investigate missing versions in the new index.
4. Once the batch is successful, promote the next batch, repeating until all traffic runs on the new index.
5. After cut‑over, decommission the legacy index.

If you need to know the exact pip version to decide whether a single‑index approach is sufficient, please share the output of pip --version; otherwise the steps above work across the 20.3‑24.x range.