https://docs.npmjs.com/misc/scope
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.
https://docs.npmjs.com/misc/scope
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.
Some standard counterarguments:
Some specific benefits:
Some specific drawbacks:
@scope/package is so great for JS because there is nothing special about require('@scope/package') over require('scope').lib = { package = "@scope/package" } or come up with a “mangling” that makes scopes special in Cargo-Rust communicationI’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
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.