[ChrisSD]

How do we decide which person/entity gets a namespace? What about namespace squatting? What if there's a dispute? What do we do about all the currently un-namespaced crates? How would Rust (the language) understand namespaces? How would cargo work with them?

[dthul]

If we really wanted, Cargo could start supporting namespaces and everything currently on crates.io could go to a new default namespace (and would still be reachable under the non-namespaced name for older versions of Cargo).

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).

[MrBuddyCasino]

> 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?

[dthul]

My initial concern was that a DNS approach would force anybody who wanted to publish to crates.io to own a domain. In a parallel thread someone mentioned that Maven allows to acquire a "com.github.username" namespace in case you don't have (or don't want to use) your own domain. That might work for crates.io as well, since it already requires you to have a Github account anyway.

[YorickPeterse]

Honestly these questions are not that hard to answer. Just look at the likes of GitHub, GitLab, or really any source code hosting platform that supports the creation of groups.

> 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`.

[Drdrdrq]

You mean like this?

> 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. :)

[YorickPeterse]

There's a thing called trademarks, and the case is indeed different for those. But even in that case, one would have to file some sort of dispute; you don't necessarily get to use the name everywhere forever, no questions asked.

[majewsky]

> 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.

[berkes]

> 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.

[majewsky]

But when you pull it, it's just `docker pull postgres:12`, not `docker pull _/postgres:12`.

[boris]

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.

[majewsky]

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.)

[ChrisSD]

Great replies so far. I'd add that if people want namespacing to actually happen they need to collaborate on an RFC (https://github.com/rust-lang/rfcs/blob/master/0000-template....). Ideally someone would post a pre-RFC to internals.rust-lang.org so it can be improved before formal submission.

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...

[jmillikin]

I've never written a Rust RFC before, but I know how to start forum topics. Let's go!

https://internals.rust-lang.org/t/pre-rfc-user-namespaces-on...

[lmm]

> How do we decide which person/entity gets a namespace?

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.

[twic]

As a baseline, just do it exactly like in Java/Maven, where it has been absolutely fine for almost twenty years.

[dthul]

I don't know Maven much so please correct me if I'm wrong, but I believe there is a substantial difference:

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.

[aorth]

I just published my first Java package on Maven Central via Sonatype OSSRH this week and when you sign up you have to verify your "groupId" (aka your namespace) using either DNS TXT records or with com.github.username where they ask you to create a repository with a given name to prove you control it.

So you could easily publish a package using the com.google namespace on your blog or whatever, but not on Maven Central.

[twic]

Meanwhile, JCenter doesn't do any checking like that.

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.

[Quekid5]

> In Maven anybody could publish a package that starts with "com.google".

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.

[vaylian]

I think it is unreasonable for people to need to own a domain (or at least pretend to own it) just to publish a package. Not everyone is part of some company or runs a website.

[dthul]

In a parallel thread someone mentioned that Maven allows you to obtain a "com.github.username" namespace based on your Github account, which is already a requirement to publish on crates.io anyway.