Have you guys given any thought to namespacing packages by developer, like Github. I've had to rename a couple of my own Python packages before uploading them to the package index to avoid naming collisions, so it definitely becomes an issue once the repository hits a certain critical mass.
I assume Rust will be around for a while (I certainly hope so - I've just started learning it!) so it might be wise to plan for growth now before it's too late to implement.
It creates a significant amount of complication. When I'm writing a blog post or documentation or in conversation, how do I differentiate between your foo and my foo? When I 'extern crate foo' in my source, which foo should it use?
While it's true that sometimes collisions happen, in practice, you just choose a new name. Everything is significantly simpler, which in software is very often a Good Thing.
I can appreciate that it adds complication to the implementation. I don't think identifying a particular crate would be an issue though, any more than identifying a particular repository on Github is. It's easy enough to talk about jdoe/foo if there's any danger of ambiguity, and links are definitive by their nature.
Just from my own experience, I know that it makes me less likely to make packages public if I have to give them odd, collision-avoiding names first - especially as I then have to use those names myself. It's particularly annoying when the incumbent package is 10 lines of poorly-written abandonware that hasn't been touched in years, which often seems to be the case.
I know this isn't an issue for Rust now but I'm thinking about ten years down the road when you have 250,000 crates on the site, 99.9% of them junk, clogging up that flat namespace. (Python's repository has more than 50,000 packages and seems to be growing at an accelerating rate now that it finally ships with a decent package installer by default.)
> I don't think identifying a particular crate would be an issue though, any more than identifying a particular repository on Github is.
Nothing is impossible, of course, but the language already has a flat crate namespace. So you could either implement some kind of layer on top of that, or change the language itself to have some sort of crate hierarchy somehow. All just to have two crates named 'http' rather than one named 'http' and one named 'requests' (for example.)
Here's another way of looking at it: shipping a flat namespace is a proven, well-worn solution. Adding in a hierarchical one, on top of the language, which has a flat one, provides dubious benefit, for significant implementation complexity.
Meh, if I wanted a 'proven, well-worn solution' I'd use C++. I want you guys to sprinkle fairy dust on my code and make the experience magical ;)
Seriously, I do get that there are trade-offs. I'm just interested in how you've been weighing up the alternatives as I do often find myself wishing that other projects I've been involved in had taken the hierarchical approach at the beginning when it was an option.
Developers who really like a name could always add something such as using "moz-foo" instead of just "foo".
I've been surprised with how few name collision problems I've had on Python's Pypi. If "z-foo" module is more usable than an unmaintained "foo" module, everybody recommends and uses "z-foo" without a second thought.
I assume Rust will be around for a while (I certainly hope so - I've just started learning it!) so it might be wise to plan for growth now before it's too late to implement.