Feature proposal: multiple upstreams, with optional masking #55
Description
One of the features I use in Nexus today, which I'd like to replace with this proxy, is the ability to 'group' two or more repositories together to make them appear to be one. I use this combine an internal PyPI-style repository of my own packages together with PyPI itself, so that I don't need to configure consumer clients with multiple index URLs.
In addition, this provides the ability to 'mask' packages from PyPI - if my repository is first in line, then requests for package 'A' will always be satisfied from my repository if it contains any version of package 'A', even if PyPI contains other versions of package 'A'. This addresses 'squatting' issues (where someone publishes a package on PyPI with the same name as an internal package and a higher version number), and also allows blocking access to packages on PyPI (by publishing an uninstallable package with the same name in the internal repository). This functionality is not available in pip, so it must be done in the proxy repository.
I'm happy to work on an implementation of this for PyPI as an example, and ensure that the design is applicable to other types of repositories as well.
Activity
andrew commentedon Apr 1, 2026
Yeah sounds like a good way to avoid dependency confusion, a proof of concept for pypi would be excellent and I can see how easy that would be to expand to other registries.
kpfleming commentedon Apr 2, 2026
I was trying to figure out a way to repurpose the existing
upstreamblock in the configuration file for this without breaking the existing use of it... but as best I can tell only theauthsection ofupstreamis actually used, theNPM,cargo, andcargo_downloadfields are not used. If that's true, then it should be safe to redesign the schema of theupstreamblock, leaving theauthpart alone.andrew commentedon Apr 3, 2026
I think #40 might also interact with this work, I'd like to get that merged soon, just something to keep in mind (caching the metadata as well as the packages for complete offline mirroring)
kpfleming commentedon Apr 3, 2026
Interesting... not a feature I would use, but I'll keep an eye on it.
mxey commentedon Jul 6, 2026
TBH this sounds like a trap that causes dependency confusion. Somebody can typo-squat an internal package of yours on a public registry. If you are explicit about the registry of each individual package, that's impossible.