I don't think Rust itself needs to know about namespaces (as in: johndoe/fuse would still just expose a crate named "fuse". Crate name collisions can be handled with Cargo's already existing renaming ability.)
Yes, then the issue of namespace naming comes up. I guess that would be less of an issue than package-level collisions or squatting, but still, you don't want any random person to get the "google" namespace for example. Which could only be avoided by either manual review or something like DNS based verification (which has lots of drawbacks itself).
Maven is doing this to great success. The namespace issue has been solved successfully, just copy what they do. It took years until they arrived at the current system, and it works well. What drawbacks are you thinking of?
> How do we decide which person/entity gets a namespace?
You get a personal one, named after your user account. In addition, you can create up to N namespaces. After that, you either have to request more or pay a small fee. This prevents namespace squatting, while still giving you the option to register a few for specific projects.
> What if there's a dispute?
First come first serve seems pretty reasonable. Just because your company is named X doesn't mean you have a perpetual and exclusive right to use that name wherever you want.
> What do we do about all the currently un-namespaced crates?
You would have to leave them, and perhaps disallow un-namespaced crates after a certain point of time. Maybe take a look at how NPM handled thsi.
> How would Rust (the language) understand namespaces?
A crate `foo/bar`, with `foo` being the namespace, should just translate to something like `use foo::bar`.
> Just because your company is named Microsoft doesn't mean you have a perpetual and exclusive right to use that name wherever you want.
Hmmm. :)
My proposal is to give everyone a namespace corresponding to their crates.io username, so if I want to publish a JSON library, it would be "user/majewsky/json".
Everything not prefixed with "user/" is a shared namespace which is handled by a team of curators. If someone wants to publish into the shared namespace, they need to apply for a package name. So if I think my JSON library should be the standard, I could apply for having it aliased to "json" or "encoding/json" or whatever. The curators would be allowed to impose an overall structure in the shared namespace to aid those who browse it.
Crucially, the curators should have the right to revoke an existing lease. If someone publishes their JSON library into the shared namespace as "json" and then later down the line abandons the project, other community members should be allowed to apply to take over that name. Of course, existing releases would stay untouched, but if I stopped maintaining my JSON library at 1.3.7, someone else should be allowed to take that over and publish 1.3.8 or later.
I would also impose the limitation that 0.x versions are not allowed in the shared namespace. If you want a nice package name, you should be ready to commit to at least a somewhat stable interface.
> How would Rust (the language) understand namespaces?
It's not hard to imagine a Rust that works with namespaced crates. What is hard is finding a solution that's backward- and forward-compatible.
The docker "hack" of using `_` is quite a smart hack here, and works well; for me at least. E.g. https://hub.docker.com/_/postgres its clear this is some "official" build.
> other community members should be allowed to apply to take over that name. Of course, existing releases would stay untouched, but if I stopped maintaining my JSON library at 1.3.7, someone else should be allowed to take that over and publish 1.3.8 or later.
This part is iffy: if you release a patch, it implies that it has backwards-compatible interface. So this will realistically only work for taking over the maintenance of the old package, not for replacing it with something entirely new. I think a version epoch might work for the latter.
(Side-note: I'm only talking about libraries here, not applications.)
Any such RFC needs to take in to account previous discussions (and appreciate that the crates.io team is small). E.g.:
https://internals.rust-lang.org/t/crates-io-package-policies...
https://internals.rust-lang.org/t/namespacing-on-crates-io/8...
https://internals.rust-lang.org/t/pre-rfc-packages-as-namesp...
https://internals.rust-lang.org/t/pre-rfc-user-namespaces-on...
Do what maven does, and follow a reversed domain name convention. Or just first-come-first-served.
> What about namespace squatting?
It's much less of a problem, because having to use a different namespace is much less intrusive than having to use a different package name.
> What if there's a dispute?
What kind of dispute are you imagining? It's much harder for someone else's package name to cause a problem for you if packages are namespaced, since there's no way for someone else's package to end up in your namespace, whereas if you have to just use a convention like author-packagename then disputes are much more likely.
> What do we do about all the currently un-namespaced crates?
Either put them in a (deprecated) unnamed/root namespace, or turn each one into its own namespace (i.e. libfoo becomes libfoo:libfoo).
> How would Rust (the language) understand namespaces?
It doesn't need to, as far as rust is concerned a package is a package - they're handled at the cargo level.
> How would cargo work with them?
Dependencies would be (namespace, name, version) rather than just (name, version). And you just... do the sensible thing? This isn't a new idea, other languages have done this.
In Maven anybody could publish a package that starts with "com.google". The namespacing proposals I have seen for crates.io assume that namespaces are exclusive to a single entitity though. So once someone that is not Google reserves the "google" namespace, Google itself would not be able to publish crates under that namespace anymore.
I don't think that's the case. If you want to get on Maven Central (at least via SonaType OSS) you have to prove that you own an email address on the relevant domain.
If it's your own private package repository, then sure, but then that's not an issue for anybody else.
So you could easily publish a package using the com.google namespace on your blog or whatever, but not on Maven Central.
Which definitely leads to an oddity in Java land - most libraries are in Maven Central, which requires some effort to submit to, but which is reasonably carefully policed, and some are in JCenter, which is easy to submit to, but is not policed. And then some libraries are in registries run by their maintainers.
Modern build tools make it easy to add registries. In practice, JCenter doesn't seem to have problems from the lack of policing. So this is very much an oddity rather than a problem.