> How do we decide which person/entity gets a namespace? What about namespace squatting? What if there's a dispute?
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.
> Everything not prefixed with "user/" is a shared namespace which is handled by a team of curators.
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.
Not bad, we might steal some of these ideas for build2 if you don't mind.
> 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.
That's something the curators would have to look out for. If you're building a green-field solution, I'd also suggest to outright reject library versions that don't follow semantic versioning. A patch version bump that changes the API? Not allowed, go bump your minor version and come back. A minor version that breaks existing users? Not allowed either. It's a really easy check. I'm honestly baffled no one's doing it yet.
(Side-note: I'm only talking about libraries here, not applications.)
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.