Repository navigation
proxy mirror fails for pypi, conda, helm, composer, swift and others: resolver has no registries registered #414
Description
Split from #411.
The mirror subcommand builds its resolver at cmd/proxy/main.go:523:
resolver := fetch.NewResolver()
proxy := handler.NewProxy(db, store, fetcher, resolver, logger)
Nothing ever calls resolver.RegisterRegistry(...), so every PURL falls through to resolveWithoutRegistry in github.com/git-pkgs/registries/fetch, which only hard-codes npm, cargo, gem, golang, hex, pub, maven and nuget. Any other ecosystem returns unsupported ecosystem: <name>.
That means proxy mirror currently can't pre-fetch at least:
- pypi
- composer
- conda
- helm
- cran
- swift
- julia
- homebrew
- apk / debian / rpm
The container case is tracked separately in #411 because images don't fit the one-URL-per-PURL model. For the ecosystems above, registering the existing registries clients on the resolver (or extending resolveWithoutRegistry) should be enough.
The eight ecosystems that do resolve use public registry URLs hard-coded in resolveWithoutRegistry (registries v0.9.3), so mirroring ignores upstream.npm, upstream.cargo_download and the other upstream settings, both from proxy mirror and from mirror API jobs (internal/mirror/mirror.go:214 → Proxy.GetOrFetchArtifact → Resolver.Resolve). Building the resolver's registries from the configured upstreams, including those eight, fixes both. git-pkgs/registries#80 tracks that resolver change. Normal client downloads are unaffected; the handlers resolve through the FromURL variants.
Missing registries support: git-pkgs/registries#62 (APK), git-pkgs/registries#96 (Swift), git-pkgs/registries#97 (Debian and RPM), git-pkgs/registries#95 (PURL qualifiers).
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.