We seem to be talking past each other since I'm purposefully trying to stick to a conceptual high-level design. Let me try to clarify:
At the moment the experience crates.io provides is that of a vertically integrated one global collection of crates. This collection serves two conceptual purposes or roles: a concrete searchable hosting provider for artefacts (the actual crates themselves) as well as an officially endorsed "universal search-engine" for crates. Again, please ignore the fact that the same index is used for both. I'm trying to get away from specific implementation details.
Given that the UX is geared towards a conceptual view of a single global collection, it makes sense that the two roles are combined into one. In contrast, the UX of apt is that of a multiple repos made available side-by-side. By default, a clean install of Debian has a set of repos.If you prefer a different analogy, then Git also provides a model and UX where multiple remotes can coexist side-by-side.
In both Git and apt, only the former role really exists - Let's concentrate on git if that makes a better analogy - there are multiple possible vendors, each has their own concrete collection of artefacts. (role 1 above). So I can see what git repositories are actually stored on github (and search them, etc) vs. gitlab vs. someone's self-hosted concrete collection of git repositories. Role 2 doesn't exist - there is no universal web-engine for git repositories. One needs to search online or check the major platforms or use the website of a project to discover what URL to clone. This is fair enough since multiple side-by-side scenarios are presented as first class citizens in the UX and the user is made aware that there are multiple possible sources for git repositories.
What I was trying to convey in my analogy is that we should make the above scenario a first class citizen in our ecosystem. The conceptual model would be there are one or more collections of crates that cargo can use to fetch dependencies. And then we need to:
- Either make it abundantly clear that creates.io is only the web-interface for one specific collection and other vendors exist on equal footing. (we just remove the notion of a single global collection)
- Or, we keep the very useful notion that crates.io is a universal search-engine for all crates (role 2 above). this would be my preferred option if possible. This requires us to divorce the search-engine aspect from a specific collection of crates. In this case, Each collection would host a specific collection of crates according to their own policies and T&Cs. But crucially our universal search engine would allow to find all crates from all vendors that chose to be listed on it. This is also a fair outcome since it allows all crates that wish to be listed publicly to be discoverable equally regardless of their specific hosting vendor.
I hope the above clarifies my design objectives.
Edit: (using Rust terminology) - I'm advocating to allow crates.io to display both owned crates as well as borrowed references to crates in its search results. In fact, it would be really cool and very obvious to Rust developers if we chose to use that exact terminology to explain the difference between crates hosted on crates.io vs ones provided by 3rd party repositories.