Repository navigation
proxy mirror doesn't support julia, cran, homebrew, swift, apk, debian or rpm #414
Description
Split from #411.
proxy mirror and mirror API jobs find download URLs through the resolver built in newMirrorResolver (internal/server/mirror_resolver.go). It covers npm, cargo, gem, golang, hex, pub, maven and nuget from the configured upstreams (#550, via git-pkgs/registries#80), including npm routes. Other ecosystems get mirror support one at a time, each tested through the mirror and then the normal handler with the upstream unreachable.
- pypi (Mirror PyPI packages #591)
- conda (Mirror conda packages #593)
- composer (Mirror Composer releases #594)
- helm (Mirror Helm charts #606)
- julia (Mirror Julia packages #607)
- cran (Mirror CRAN source packages #608)
- homebrew (Mirror Homebrew bottles #610)
- swift (Mirror Swift registry releases #611)
- apk (blocked on Add an Alpine APK repository client for v2 indexes registries#107)
- debian (blocked on Add a Debian repository client registries#97)
- rpm (blocked on Add an RPM repository client registries#108)
Container images are covered by #411.
Activity
andrew commentedon Oct 12, 2026
The empty resolver is still present on main, but registering clients alone will not cover the full list above. There are no existing Swift, APK, Debian or RPM registry clients to register, and mirroring currently drops PURL qualifiers, which loses repository and platform selection.
I'd start with ecosystems whose existing clients return usable artifacts. For each supported case, test through the mirror command and then verify that a normal package-manager request retrieves the mirrored file with the upstream unavailable. A successful download alone does not establish that the proxy can serve it from the expected cache entry.
Missing artifact resolution belongs in
git-pkgs/registriesfirst. Track those requirements separately, along with the repository and platform selection needed for the remaining ecosystems.pinguinfuss commentedon Oct 13, 2026
One more thing for whoever picks this up: the ecosystems that do resolve today (npm, cargo, gem, golang, hex, pub, maven, nuget) use the public registries hard-coded in
resolveWithoutRegistry, soproxy mirrorignoresupstream.npm,upstream.cargo_downloadand the rest. A setup pointed at an internal mirror still mirrors from the public registries.If the registries get registered on the resolver here, building them from the configured upstreams, and registering those eight as well, would fix both.
ResolveWithOptionsalready takes the download URL from the registered client.Mirror packages from the configured upstreams
Mirror conda packages
Mirror Composer releases
simonchrz commentedon Oct 25, 2026
Status: PyPI (#591), conda (#593) and Composer (#594) are in. Open now are Helm (#606), Julia (#607) and CRAN (#608). Each is tested through the mirror and then the normal handler with the upstream unreachable, and checked against the real registry with the native client.
Still blocked:
proxy mirrorcan't pre-fetch container images #411.simonchrz commentedon Oct 25, 2026
Correction to my last comment:
proxy mirrorcan't pre-fetch container images #411.Debian and RPM are still waiting on git-pkgs/registries#97.
[-]`proxy mirror` fails for pypi, conda, helm, composer, swift and others: resolver has no registries registered[/-][+]`proxy mirror` doesn't support julia, cran, homebrew, swift, apk, debian or rpm[/+]