In JS one can use @scope/package. Was anything like this proposed for cargo. It seems it might help both in grouping related sub-crates of bigger projects, and potentially help with crate name squatting issues.
I like this approach, and unlike most of the proposals for adding namespaces to crates.io, it’s additive/complementary.
I’d seen some earlier proposals for something like claiming a myprefixname-* / myprefixname_ namespace on crates.io, which could be done entirely on the crates.io side without making any changes to the Rust crate/module system.
Clearly that would come with a lot of caveats, like perhaps all of myprefixname* including the myprefixname crate being unregistered, but it seems like a simple, unobtrusive way to retrofit a namespacing mechanism into crates.io.
“This just moves the squatting issue to scopes”
“Unscoped packages are privileged over scoped ones”
“How do you map scopes onto Rust identifiers”
Some specific benefits:
Crates’s global namespace was inspired by npm’s (as the most recently notable package manager)
And this is npm’s solution to the perceived problems with a global namespace
Some specific drawbacks:
@scope/package is so great for JS because there is nothing special about require('@scope/package') over require('scope').
Rust would at least have to require lib = { package = "@scope/package" } or come up with a “mangling” that makes scopes special in Cargo-Rust communication
I’m neutral on @scope versus scope- versus any other proposed namespacing proposal. I still believe namespacing is useful, but doubt how much “author” namespaces will be used for “serious” packages.
crates.io has 25K packages, and custom registries are now stable, so backwards compatibility is a serious concern.
Hyphen prefix seems like a workable solution with minimal overhead (becomes only a policy of a registry, rather than a feature requiring changes in the Rust language and Cargo). Previous post about it: Namespacing on Crates.io