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.
