Crates.io package policies

internals policy
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.

2 Likes
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.

6 Likes
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.

2 Likes
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 crates.io: Rust Package Registry and crates.io: Rust Package Registry

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.

58

I’m really sorry to bump this old discussion once again, but back in 2014 when the decision have been made to keep namespaces out of picture, Rust ecosystem simply was not that big.

Time passed since then and we have a lot of wonderful opensource Rust projects, and in opensource, at the certain point of project’s life, forks are starting to emerge for variety of reasons:

  1. Discontinuation of original project: this issue is semi-solved by ownership transfers, so that’s just a social communication issue now.
  2. Strong disagreement in the project future: this is a lot more nasty, as solving the problem by continuing to work together on the same crate sometimes is simply impossible, so forks start popullating crates.io with libname2, libname-plus and other not very descriptive names, making it’s harder for the end user to decide which one should they use.

Namespaces would solve the later problem the best, as they would provide an additional semantic entity of package context (e.g the name of company that’s working on the project).

This is not a made up example, we are really having this issue right now: after the startup’s unfortunate death due to management issues, the development team was forced to seek for another investor and fork the project code to continue development under the new company. There’s no viable option other then to rebrand the whole thing, which has it’s unfortunate implication of building the product identity from scratch, while with namespaces users would just move to our version, as it has more development activity.

Solving the issue by ownership transfer is not viable in our case, old owner wouldn’t give up the crate even though there are no more devs or funding to continue development.

I really hope we could revisit this issue and have namespaces discussion reintroduced on agenda. Thanks.

1 Like
59

I also dislike the situation, but I'm still not convinced that it would truly be solved by namespaces.

For example, GitHub has namespaces, and there's a bunch of forks of homu:

Would you describe homu as a well-maintained piece of OSS software with a bright future ahead? Because I know of at least one OSS project that switched off of homu specifically because of its unclear ownership situation. Owning the top-level bors-ng/bors-ng namespace is just a better look. Nobody likes to be the "unofficial fork".

p.s. is @indirect on here? It seems like you could speak both to your own situation with homu, as well as the experience of rubygems.

60

From a crate user standpoint, that could be just solved by sorting the crates in the search results based on the bigger version numbers, that would help to avoid confusion and unmaintained forks would sink down in the search.

I see what you mean about unoficial forks, but IMHO most of the times the situation is pretty clear regarding which fork is the “official” one, measured mostly in better support and activity.

Would like to hear about rubygems too :slight_smile: