In discussions about cratesio features/policies one of proposed workarounds is to make an alternative registry instead, which could have the desired features.
I’m considering doing that, but the details of how it would work turn out to be pretty messy. Alternative registries are fine for adding a few new private packages on top of cratesio, but a cratesio replacement is very problematic.
Silo of crate deduplication
The biggest obstacle I see is that the way cargo deduplicates dependencies. Each crate from each registry is considered to be a completely different separate crate. Technically, it makes a lot of sense, but IMHO it means that mirrors of cratesio are infeasible.
If I simply mirror cratesio crates, then they won’t pull dependencies from my registry, causing every top-level crate to be a dupe. If I rewrite them to pull dependencies from my registry, it gets even worse.
A user using my mirrored crates with deps from my registry can’t use any other registry or git deps which depend on cratesio crates, even indirectly. As soon as someone installs a crate that “contaminates” the build with deps from cratesio, it will pull a highly problematic parallel universe of non-deduplicated dependencies with it. That’s not just wasteful, but for crates with the
link attribute (
sys crates) or shared types/traits (
serde) it breaks compilation.
I’m afraid it’s too much to ask from users to switch to an alternative registry as the only registry, and have their builds bloat or break if they accidentally violate that exclusivity.