Crates.io package policies


#41

Say what you want about the merits or lack thereof (I would’ve preferred to have namespaces, as well), but the discussion ended when Rust 1.0 came out.


#42

Huh, I’d think this would be easy to retrofit. I’ll existing package names become top-level. Not elegant, but totally sound.


#43

Also, I was thinking about this earlier today because https://github.com/rust-lang/rfcs/pull/1133 is complicated by the fact that new stdlib crates may be impossible to ever put on crates.io unless we are vigorous about reserving names.


#44

But do crate names actually matter? My understanding is that crates are really anonymous, and it’s the job of a build system (currently cargo) to connect a certain rlib with extern crate foo. So you can, for example, have two completely different and orthogonal naming schemes on cates.io (and add more if you need to), like

[dependencies]

// default global namespace
time = "*"

// maven style
std = {
    groupId = "rust"
    artifactId = "libstd"
    version = "*"
}

So you can even have different aliases for the exact same crate. There can’t be any naming conflicts between your direct dependencies, because, again, crates apparently have no names, and so you theoretically can introduce explicit names in Cargo.toml yourself.


#45

You already can make the name of the crate different than the name of the package. I do this in winapi where you depend on kernel32-sys from crates.io, yet do extern crate kernel32;. So multiple crates could easily use the same crate name, and even better, Cargo has no way of differentiating between them! If you depend on two packages that choose the same crate, you’re stuck. While this problem would be worse with namespaces, it already exists under the current system, and I’m surprised nobody has attempted to solve this yet.


#46

Certainly if they did go up on crates.io, we’d like to use the same names for them, right?


#47

I wrote a thing about the history of package managers and where cargo fits in; several parts of the pains described in previous managers fit into the decisions we made here, looking back.


#48

Thanks for the link to the history. As far as I can tell, the part of it that seems specifically relevant to this package namespacing discussion is the following:

But all was not well in package manager land. While you can install mojombo-grit and grit at the same time… do you want to? For those of you who don’t know Ruby, it has no real namespacing, so… yeah. It got messy. Furthermore, since you could so easily use these forks, people didn’t bother contributing fixes back upstream. They’d just say “oh cool I pushed a patch to steveklabnik/grit so use that instead.” And now you had hundreds of forks of popular projects with their own little incompatible extensions. It was madness. It was not a good time. Nobody was happy.

It seems like there are two points made above: first, that Ruby didn’t have sufficient namespacing in the language to prevent conflicts between different forks of the same crates; second, that the ease of using forks meant that people didn’t put in the effort to merge their changes upstream.

As far as I am aware, Rust has namespacing in the language to prevent the first problem. Concretely, suppose that crates.io had namespaces, and my crate has one dependency using foo/crate while another was using bar/crate. What problem does this actually cause?

Having hundreds of slightly different but incompatible forks of popular projects is also a problem, but it’s not a problem caused by the availability of namespaces. Making it harder to fork existing crates doesn’t make it easier for people to merge their changes to a single upstream, which is the more important problem to solve. Moreover, there’s lots of good reasons why someone would want to fork a crate: because the maintainer is unresponsive, because there are different visions for what’s important, because there are different standards of quality, etc.

I remain deeply unconvinced that it’s a good idea to have a single global namespace for crates, for many of the reasons already described at length by others in this thread.