Transition to namespaces

[tliron]

crates.io began, like PyPi and other library repositories, with a flat namespace.

This means that crate names can ever only be used once, and it has some painful consequences for both publishers and users.

Many "good" names are already taken. Moreover, it creates an anxiety about naming, which leads to people "parking" good names for which they don't have a project yet. Or just modifying their names to be "less good", to avoid conflicts with existing names, by adding silly and confusing prefixes and suffixes or other mangling. That's where it gets painful for users. Compare serde_yaml with serde_yml. Or many crates that add -rs. I've even seen crates that change from underscore to dash delimiters, or vice versa, in order to differentiate further! This is super confusing to everyone.

To me, the obvious solution is to prefix crate names with a namespace, which can be the name of the developer, organization, project, etc. So there could be acme/serde_yaml and radical/serde_yaml. Woosh, the anxiety about naming is gone and everyone can choose whatever name works best for them.

Of course, the worry is about what to do with the current state of things. I would suggest the following transition plan:

First, create a default (or legacy?) namespace, to which all current crates will be moved. When referring to crates without a namespace (in Cargo.toml, cargo add, etc.) this default namespace will be automatically added. So everything would continue to work as is with current crates.

However, we would lock the default namespace from any new crates. Newly published crates would have to be in new, non-default namespaces.

Honestly, the solution can end with this. default would remain frozen in time and that's that. A memory of cargo.io's past. :)

But we can do some more things:

We could allow aliasing for these "legacy" names, to allow them to transition to a new namespace. For example, I have an awesome crate, which is really default/awesome, I could alias it to a new radical/awesome namespace. The alias means that a Cargo.toml can use radical/awesome, default/awesome, or just awesome, and it would point to the same exact crate with all the same versions. We can decide that one of these aliases is the "canonical" name (likely radical/awesome), and that's what would be used in Cargo.lock and the like.

We could furthermore decide that eventually the default namespace would be deprecated, perhaps coupled with other breaking changes to cargo. That means that well before the sunset date we would send emails to crate owners that they need to transition their crate to a namespace (aliased?) in order to keep it published. At the sunset date the default namespace would no longer be available.

Obviously this last step would be more controversial, as it would break some very old projects. We can come up with ways to make this less bad. For one, if this is tied to a specific edition of cargo, then we could say that the default namespace would remain accessible only to these older editions of cargo. Newer editions would error out, but older projects based on the older edition would continue building and working as is.

One could also argue that it's not the end of the world if very old projects stop building. If many years have passed without these crates being maintained, then maybe they should be sunset? Anyway, we have options here.

A second issue we would need to solve is what to do with module naming in Rust. If my Cargo.toml has both radical/awesome and competitor/awesome as dependencies, how would this affect module name paths? They can't both be awesome::*, right? Here there can be some sensible heuristics to keep things coherent and ergonomic.

First, if there is no naming conflict in the dependencies then there's no reason to complicate things. If we only have radical/awesome than awesome::* could be mapped to it.

Second, if there is a naming conflict then cargo can force you to add package to at least one of them, e.g.:

[dependencies]
radical/awesome = "1.2.3"
competitor/awesome = { version = "4.5.6", package = "awesome2" }

I hope this all makes sense and I would be happy to hear about alternative solutions as well as arguments to keep things as is.

[syphar]

This is already in the works, but is a bunch of work.

Accepted RFC: rust-lang/rfcs#3243

• rustc tracking issue: Tracking Issue for Packages as (optional) namespaces rust#122349
• cargo tracking issue: Tracking Issue for Packages as (optional) namespaces cargo#13576
• crates.io tracking issue: Tracking Issue for Packages as (optional) namespaces #8292

[Turbo87]

FWIW the cargo team has pointed out that this is explicitly not seen as a generic namespacing solution and only covers a small subset of the desired features.

I personally think proper namespacing would be better and at this point I'm slightly worried that implementing this almost-but-not-quite-namespacing will prevent us from ever implementing it properly.