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

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

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

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

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

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

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

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

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

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

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]

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

[vaylian]

give everyone an equal chance to pick a good name