Crates.io package policies


#41

Say what you want about the merits or lack thereof (I would’ve preferred to have namespaces, as well), but the discussion ended when Rust 1.0 came out.


#42

Huh, I’d think this would be easy to retrofit. I’ll existing package names become top-level. Not elegant, but totally sound.


#43

Also, I was thinking about this earlier today because https://github.com/rust-lang/rfcs/pull/1133 is complicated by the fact that new stdlib crates may be impossible to ever put on crates.io unless we are vigorous about reserving names.


#44

But do crate names actually matter? My understanding is that crates are really anonymous, and it’s the job of a build system (currently cargo) to connect a certain rlib with extern crate foo. So you can, for example, have two completely different and orthogonal naming schemes on cates.io (and add more if you need to), like

[dependencies]

// default global namespace
time = "*"

// maven style
std = {
    groupId = "rust"
    artifactId = "libstd"
    version = "*"
}

So you can even have different aliases for the exact same crate. There can’t be any naming conflicts between your direct dependencies, because, again, crates apparently have no names, and so you theoretically can introduce explicit names in Cargo.toml yourself.


#45

You already can make the name of the crate different than the name of the package. I do this in winapi where you depend on kernel32-sys from crates.io, yet do extern crate kernel32;. So multiple crates could easily use the same crate name, and even better, Cargo has no way of differentiating between them! If you depend on two packages that choose the same crate, you’re stuck. While this problem would be worse with namespaces, it already exists under the current system, and I’m surprised nobody has attempted to solve this yet.


#46

Certainly if they did go up on crates.io, we’d like to use the same names for them, right?


#47

I wrote a thing about the history of package managers and where cargo fits in; several parts of the pains described in previous managers fit into the decisions we made here, looking back.


#48

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.


#49

This discussion seems dead, but since I just got very annoyed at the lack of namespaces, I thought I’d add my experience just to document that yes, its still annoying.

I’m experimenting with embedded stuff, and there are some projects initiated by japaric that follow a certain naming pattern, e.g. stm32f30x-hal. Those names make sense because they refer to a real life family of MCUs, there are f1, f3, f4 etc. I found that there are crates that follow japaric’s naming pattern, but do not contain anything useful and haven’t been updated in a long time.

This is essentially a discovery problem - I’d like to know for which MCUs there are useable crates, but I have to click every single one of them and see what it contains, which is sometimes not obvious. If there was an “official” namespace, be it japaric’s own or some embedded working group one, I could trust that and navigate the repo much more easily.

Namespaces could be brands that one could trust, because there are gatekeepers. Crates could be named in logical, consistent ways, without fearing squatters or introducing “creative” names that would confuse more than they would help.


#50

https://github.com/rust-embedded/awesome-embedded-rust might help?


#51

Thanks for the hint, I know that page. My point is that I wish something like that was unnecessary. Namespaces are really just one piece of the puzzle.


#52

I think a good and relativley simple solution would be an official wiki (on crates.io?) where the users (everyone?) could organize the crates into arbitrary categories, groups, trees. For discovery you could browse the wiki and you wouldn’t really have to care about the name of the crate.


#53

Yeah something like that. Trust in a given piece of code via association to a branding, e.g. a namespace, plus crowdsourced labels / ratings / categories to facilitate discovery. In the 90s we used to have “web directories”. They don’t scale infinitely, but thats not needed. In a given category, there are only so many libraries that really matter. Something like a wiki page as a starting point is not the worst idea.


#54

We already have https://crates.io/categories/ and https://crates.io/keywords/


#55

Thanks. I did not know those exist.:confused: They are not easily discoverable and way too rigid at first glance. I think a wiki is a better solution. If people feel like hosting their collections on random GitHub pages then the current solution is probably not a good enough solution.


#56

We may be able to make them more discoverable, but each crate has them on their page, so there is some way to find them, at least.

Categories is rigid, but tags are 100% free-form. That’s one of the primary differences between the two.


#57

The awesome lists predate the crates.io categories, and unlike the categories, the awesome lists are curated. That’s why they both exist.