Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Packages really should be namespaced #58
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
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:
We may wish to more formally support the idea of moving a package to another namespace. That could be accomplished as follows:
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
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
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 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
Some of the remnants can still be found on
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.
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.
referenced this issue
Nov 28, 2014
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:
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.
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.