Packages really should be namespaced about crates.io

[skade]

I don't like user namespaces and prefer global ones, also because of bad experiences in the past.

github was publishing gems for a while that were namespace by username (they used $(gh-name)-$(gem-name).

Some of the remnants can still be found on rubygems.org, e.g.. http://rubygems.org/search?utf8=%E2%9C%93&query=rest-client (look for usernames, e.g. technoweenie).

This lead to encouraging self-released forks over working with the library owners to get things fixed. Global names, in my opinion, encourage collaboration. Also, namespaced names communicate badly, especially orally. In my opinion, this created more harm then good.

Landgrab situations happen at the beginning of such systems and there will be one or the other joke (I own "extasy" on rubygems for the sole reason of keeping Rubyists from releasing a gem of that name...), but that is a moderation problem that no amount of technology can fix. The stewards of crates.io are, in my opinion, perfectly within their right to take obviously grabbed names from their owners.

What I'd like to see, though, is a possibility to release multiple libraries as a group, that can act as a namespace.

[steveklabnik]

The team has discussed these issues at some length and we've written up a more formal explanation of our namespacing policy at http://discuss.rust-lang.org/t/crates-io-package-policies/1041. Further discussion should happen there.

[pnkfelix]

FYI here is the corrected link for @steveklabnik's previous post: https://internals.rust-lang.org/t/crates-io-package-policies/1041

[aatxe]

@mahkoh gave up irc after a great deal of discussion on the IRC (Known nicknames: arrrrrrrrr, bsssssssss, Partially masked hostname: moz-q9i5au.dynamic.qsc.de). He's now squatting on irc2. He definitely has more packages. He previously linked to a list of packages here.

[tilpner]

This is a list of names he sent me with packages he reserved. To his defence, he intended to hand them over to people who would make good use of them, and reserved them just to prevent others, who might not do that, from reserving them.

[aatxe]

Considering the amount of difficulty he gave me, I don't believe that to be his genuine intentions. Either way, the issue needs to be addressed.

[tilpner]

I found the relevant IRC logs. I can't tell if what he said is true, but I can see some reason in what he said.

[alexcrichton]

Our goal for the initial release of crates.io was to be an early adopter phase to flesh out issues such as this before the 1.0 timeframe. Our policies around crates.io are still under development. At the upcoming work week (next week) we plan to discuss policies around crates.io which will likely conclude in a resolution of this issue one way or another. I'll keep you posted!

I'm definitely in favor of namespaces. I can see some downsides to them as @skade points out but on the other hand I think the github model works really well. Of course there will be some forking (I think that's good) but, as with github, people still tend to work together on the bigger things.

[skade]

Github, in my opinion, works well for sharing code, but not for publishing. I don't think the model when it comes to package repositories not one.

I suppose it depends on your development style but I see the two as intimately connected. In that way, I view crates.io as an extension of the development I do in my repositories or organization repositories. I don't see an advantage to forcing more consolidation artificially by restricting available names. If we have good discoverability and metrics, folks will gravitate toward collaboration and good packages will clearly emerge.

Hackage is an example I am familiar with that uses global names and it doesn't work well for a number of reasons:

• Sometimes packages are abandoned (this happens a lot for smaller things). They could be forked and continued in a new namespace but instead folks are more likely to start from scratch with a new name and different design. This is wasteful.
• Sometimes a critical feature is needed for a particular application and a library author does not want to include it for whatever reason. It should be feasible to maintain a minimal fork under another namespace rather than 1) being blocked indefinitely by upstream, 2) forking under an entirely new name even though there is no intention to maintain a full blown forked project, etc., 3) completely avoiding the crates.io registry and only using repos.

Not having namespaces would just reduce usability. People will still fork if they need to, we'd just be making things harder for them. The fact that some people have usernames that others find unprofessional or awkward to say aloud (I think that's what you mean) don't seem like strong reasons to avoid it.

[tarcieri]

Because this ties into the authorization model, I think it would be good to figure out what that will look like comprehensively, along with the overall security model of the system.

I described one approach to this (TUF) in #75