Packages really should be namespaced

[lilyball]

Right now it's far too easy to grab a package name and hold it hostage, even if the name is generally recognized as belonging to another project, or even if you don't actually have anything to publish yet. For example, both bindgen and irc have been claimed, apparently by @mahkoh (which isn't even exposed in the interface).

The proper solution to this is to namespace packages. They can be namespace using the GitHub user/organization name of the publisher. This way everyone can publish their own package, without worrying about collisions, and without any confusion when depending on a package as to whether it's the "official" package or not (well, for packages whose repositories are hosted on GitHub, which is likely to be most of them).

Packages with multiple owners can be deal with as follows:

• Anyone added as an owner to a package can still have their own namespaced version of the package, i.e. if the user bob adds the user alice as an owner to bob/crypto, then alice can still have an independent alice/crypto package. This is important because the new owner might have already had a package with that name, and that needs to be preserved. Similarly, they may wish to keep a parallel fork for other reasons, or may wish to simply be able to use that name later if they are removed from the ownership list at a later date.
• People who are owners on a package under someone else's namespace can publish using an extra flag to cargo publish that identifies the namespace. Similarly, .cargo/config could learn how to record the namespace of a given package (presumably identified by path) to avoid having to remember to use the flag every time. I don't think it makes sense to put the owner name into Cargo.toml because you probably don't want to commit this to git (if for no other reason than anyone who forks your git repo will not want that owner information because they can't publish your package).
• Any original owner who is removed from the owner list of a package does not regain use of the name. Because crates.io wants to be a permanent archive, the namespaced package name must continue to identify that package. However, it should be rare for someone to want to be removed from the owner list of a package under their namespace, so that's unlikely to be an issue.
• Any package that wishes to switch namespaces, because of an ownership transfer, can simply be published to the new namespace. The existing package will remain the old namespace, for archival reasons.

We may wish to more formally support the idea of moving a package to another namespace. That could be accomplished as follows:

• Copy the entire history of the package to the new namespace. This means anyone depending on any existing version of the package at the old namespace can update to the new namespace and get the same package.
• "close" the old namespaced package, such that no new versions can be submitted, and display this on the package page, with information on where the new package can be found.
• When updating Cargo.lock, any package that is found that is closed can continue to be used, but cargo should display a warning telling the user that the package has moved and they should update their Cargo.toml.
• We may wish to support the ability for a user to reopen a "closed" package, but that should be rare enough that it can be handled manually. My recommendation would be to at least require any new published package be at least one "breaking change" higher than the highest version that existed when it was closed (so any ~ version specs will not pick up the new version).

With these changes in place, we could still support un-namespaced packages. These would be manually curated so as to ensure that nobody takes a name that is reasonably understood to refer to some other package (such as taking bindgen). These top-level packages would really be aliases for the namespaced version, and Cargo.lock would identify the namespace that it resolves to (and cargo would either warn or error when updating a lockfile if any top-level package resolves to a different namespace than before).

This would serve as a weaker form of the archival guarantee of namespaced packages. A top-level package can change to identify a different package than before, if it makes sense to do so (e.g. an error was made, or an unofficial package gets claimed by the actual owning organization). For this reason it is recommended that libraries always use the namespaced name (since they aren't supposed to check their Cargo.lock into version control), but binaries are free to use the top-level name (since cargo will warn/error if the namespace resolution changes). This top-level naming is intended to be primarily useful for people trying to find packages. And the web UI can be updated to make it easier to avoid mistakes, by using the full namespaced name in the "Depend" code snippet.

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

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

[ghost]

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.

[ghost]

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

[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