Cargo, as a package manager, needs a way to identify the published packages. Currently it uses the crate name registered on
crates.io as the identifier, which is probably a timebomb imao.
The registration policies of online communities have evolved over time. Before 2010, often I registered for a unique username in a community, and that username was displayed to identify who I was.
Later on, almost all modern-designed platforms adopted the concept of "display name" which doesn't need to be unique. Of course, people still need to check your unique username if they want to identify you, but "display name" is there to show how you want yourself to be normally called, instead of being a unique identifier in said community.
For popular platforms, unique usernames are often not intuitive. A person with a display name
John Smith might choose a username
name-too-common-haha. In practice, the username is hardly ever typed by anyone else, and is typed by the owner himself only when logging in.
In short, it is common for entities to be labeled with a long-and-ugly unique name (identifer) together with a short-and-nice display name.
Short identifiers are of course, possible, but often not available for those who want to name themselves with a popular name. It's not his fault if someone wants to be called "John Smith" even if he knows there're lots of John Smith's out there. Everything is ok as long as people can still identify him with the unique username.
Back to crates.io
I've seen a lot of threads related to
crates.io naming, namespacing, squatting, etc. I think a lot of people have missed a point.
Namespacing is just a means, not the goal itself. As for me, I just want to be able to tell users how I want my library to be called in their code by default, even if there're crates with the same name registered on
Actually, when people are forced to rename their crates simply because
crates.io name conflict, they don't often come up with new names that better suit the nature of those crates. More often than not, a prefix or suffix is used, which is just an alternative to namespacing.
Instead of introducing namespaces which, in effect, make the fully qualified name of every crate "long-and-ugly", we can introduce a new attribute equivalent to "display name" of a crate, which in real life works the same way as a "default alias".
- Crates are displayed and used with their desired names from their creators, instead of being renamed solely to avoid name conflicts, which might lead to less intuitive names appearing repeatedly in code if their users don't manually alias them.
- Searchbox in
crates.iowould treat the display name the same weight as a crate name. And the keyword correlation for both names should not be counted twice (only the larger one should be taken into account). There's no reason a crate named
foolooks better than another named
myorg-fooand is placed in front of it simply because the former one is "first-come, first-served", even if the latter one is intended to be called
foowhen it's designed, and is better in quality.
- Lib developers wouldn't need to register names in advance for reservation. They wouldn't need to do a last minute crate-renaming either. Whether to remove empty placeholder crates on
crates.iois another issue, but as squatting wouldn't do much benefit any longer, fewer people would be doing this or worrying about it naturally.
- Backward compatibility is good, as the new "display name" attribute is completely incremental, and it defaults to the original name of the crate. If we implement it as a "default alias" for
Cargo.toml, as we can now alias a crate with the rename-dependency Cargo feature, then legacy code should not be broken by this change. In fact, the change is just automating what is regarded as a solution / workaround in this issue
- Developers who are familiar with old
crates.iomight accidentally import wrong crates, but only if they manually type
cargo add displayname/
displayname = "<version>"instead of copying the command (which would correctly use cratename/rename-syntax over displayname) from the page.
- Similarly, an experienced developer might come across code depending on a crate whose name is familiar to him, but not the actual crate that he knew - but this is something that might happen even now with dependency-renaming
- Some people don't like the idea of two names for one crate, and the possibility of multiple crates sharing the same display name, even if it's a simplified version of the namespacing approach.
Cargocan no longer assert that the crate name on
crates.io(identifier) equals the crate name in the source code of it. Some extra mapping would have to be done. Or, if this feature is not implemented, then the crate developer would still have to manually rename the crate in his code. Hopefully with refactor tools this is not a big issue.
crates.iodisplay name & install command should be changed accordingly.
crates.iosearch mechanism should be adjusted (see above).
This proposal aims at splitting the
crates.io crate name's role as 1) a unique identifier for
Cargo and 2) a way that the crate should be referred to in source code / doc / online contents, into two names. Hope it helps.