[anonova]

I find it absolutely frustrating that Rust packaging/crates.io doesn't support namespaces. The arguments I've read are always theoretical/what ifs, but I've yet to be convinced the current situation is better than the practical benefits of namespaces.

[TheCycoONE]

Conversely the arguments I've heard for namespaces is that multiple people want to reimplement or make bindings for the same C library.

In maven central, in my anecdotal experience, namespaces usually either distinguish forks of the same library, or to group related libraries. There has never been, in my experience, a case where I wanted two packages with the same name in different namespaces.

I think a better system of handling unmaintained crates; with the possibility of reclaiming a name would go a long way with the author's use case. I don't have any great ideas here: package with no update in some time (a year?) is eligible. Someone requests to take over name - the author is notified and has a period of time to click an "I'm still here" button. If they don't - new author gets the name. Some 'super version' number is incremented so crate authors opt into the new or old foo. That last part is where I'm the most hesitant.

[stefan_]

Of course a single project is very unlikely to depend on two different packages with the same name. But a global repository of all packages is conversely extremely likely to have many many people all wanting one name - it's essentially a .com registry.

Reusing project names is just a straight no-go when that is what other peoples projects depend on. As soon as a package has a dependency, (name, version, source) need to be absolutely immutable.

[boris]

As the person you are replying to suggestes, a version epoch could be a solution.

[mlindner]

There's a bigger problem that someone has reserved a ton of common names and they're all empty projects with nothing in them.

[viraptor]

Or even in a non-malicious case: https://crates.io/crates/logger

"logger" is now forever a middleware for the iron framework. Same with "router". Iron is pretty much obsolete now.

[rat87]

that sounds like a good thing.

It might have been good if the rust team themseleves had pre-squated

get rid of all the common names arguments and have everyone use prefixed or unique names

[rkangel]

Everyone complains that 'fuse' is taken so they have to use something with qualifiers (e.g. rust-fuse), and then they propose to fix this with a solution that requires that everyone uses qualifiers for everything.

It's a bit more consistent in that no-one gets good names, but is it really such a problem that a few people happened to get in early enough that they could call their library 'fuse'?

[jmillikin]

I'm fine with qualifiers, but I don't want useless qualifiers.

"rust-" or "-rs" is useless because it's on crates.io. "lib" or "-lib" similarly, unless it's part of a pair with a binary of the same name.

Here's a partial list of FUSE server implementations on crates.io:

  * fuse
  * cntr-fuse
  * drakey-fuse
  * fuse_mt
  * fuser
  * fuse-rs
  * polyfuse
  * fuse3
  * yarf

Why do we make people come up with custom prefixes or opaque codenames when they could all be ~user/fuse ?

[tibbe]

Why not user-fuse?

[atombender]

Names can be powerful. Owning a name like "fuse" implies that this is the thing called "fuse".

A flat "top level" namespace encourages treating names, especially short names, as something with intrinsic value. You end up with the same problems that the .com namespace has, such as name squatting and first mover advantage.

Qualifying all names removes this property from names and levels the playing field. There's no value in "owning" github.com/somename/blah. Or, to take the NPM approach, @somename/blah.

[Macha]

But then everyone just wants @fuse/fuse rather than fuse. If one project is @fuse/fuse and the other is @atombender/fuse, the first is going to have more legitimacy, just as if they were called fuse and atombender-fuse.

[atombender]

In reality, that does not seem to have happened, because the top-level is your name, and people have a different relationship to their own "branding", for the most part. People/companies also usually have more than one package.

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

[twic]

Having namespaces seems like an absolute no-brainer to me, and i find the visceral opposition some people have to it entirely baffling.

[renewiltord]

Why not `anonova-logger` instead of `logger`. You can namespace by naming if you want.

[j88439h84]

One thing is that anonova doesn't control the anonova namespace.

[rat87]

sure but who is going to steal it?

it seems easier to do that for the common case then deal with the complexity of namespaces

[renewiltord]

Fair enough.

[rat87]

what are the practical benefits of namespaces that you don't get with

username_logger, username_fuse, etc.

?

A lot of the supposed benefits seem like downsides. The ability to have

bob_ward/docker and lilly_smith/docker seems like a misfeature

I guess you could argue it makes to avoid malicious packages w/ similar spelling but then they could just try the same thing with even less suspicion w/ similarly named namespaces

[peacefulhat]

What do you want to do with namespaces? I don't understand.

[jgraham]

What I personally want from namespaces on crates.io is basically the same as I want from org names on GitHub; the ability to manage permissions at the level of a organistation rather than each package requiring a unique setup, making it harder to audit and admin all the packages belonging to an org. It also seems like a win for consumers to know when they're using code from a specific vendor vs when they aren't. The consumer trust problem you can possibly solve with naming conventions — although it's hard to ensure that everyone has the same conventions unless it's enforced — but the admin problems you can't.

[DougBTX]

Yes, it would be great to have packages grouped by organisation. It would make it much easier to see in a package list how which organisations you're depending on, rather than just how many crates.

[DougBTX]

Imagine if every repository you pushed to GitHub had to have a globally unique name, rather than account/whatever-you-like.

[qayxc]

So account-whatever-you-like then?

[Whitespace]

That is not the same, because ownership of _account_ isn't enforced if it's just a string. Imagine someone else uploading qayxc-resume, for example.

[vaylian]

give everyone an equal chance to pick a good name