Crates.io package policies

What will happen if crates.io start running out of free space (and/or of money to support larger hosting)? Will old version of crates be dropped? Will old projects stop being compilable? Will it be easy to restore content from developers machines (like with Git)?

How much crates.io and its crates depend on Mozilla being alive?

For the sake of a discussion, I would stick to "OSI"-approved for "open source". Otherwise, no discussion can be had at all, as it can be anything.

Well, how does DMCA come into play then (which only applies to copyright)

1 Like

Well, my point was that may be we should stick the policy, not only discussion :slight_smile:

Ok, probably I'm not so familiar with US laws, I was sure that DMCA also applies to trademark use. Anyway, as far as I understand, DMCA just simplifies request for removal here, while removal on behalf of trademark usage would be done just by the fair will of crates.io, or by court decision.

Crates are hosted on Amazon S3, so it will never run out of space. The design of cargo in that respect is pretty similar to Rubygems.

You can always download the crates and use them without the cargo web service.

Any update on the “Organizations & related packages” feature? What are the current plans for “grouping crates”?

So I’m also highly disappointed by the fact that namespaced packages has been out of the pictures. Package and source code management is defacto equivalent to file management? Who of you has seen a computer with a flat file system? No hierarchy = no order. Some of the reasons for making “creative names” is pure bollocks to me.

  1. Make creative names - I’m not creative bloody hell, would have study arts if I was, I’m a technical person with OSD and I don’t want to have the burden of figuring out a “good” or “bad” name for my package. This argument is so invalid… it is basically fully estetical and unless you like dictatorship it makes no sense. Also, and VERY importantly, if you have namespace you also have the option to write any creative name you want for your package. Noone will ever stop wycats to naming his package as wycats/piston rather than wycats/game-engine. In other words you the freedom to do what you want, while the previous option you are taking away one of the possible freedoms. Even if you want allow packages to be published on flat namespace, but reserve each username or something for each user. If people want let them publish how they want. Otherwise this is so anti open.

  2. Tags are never going to cut it. Hierarchies make sense, not only for source code, not only for industry, they make sense for life on earth, for artificial intelligence, for organizations, for goverments, for games build on top of APIs build on top of game engines, built on top maths libraries … and on and on. Tags are designed as a commentary addition. Also as mentioned if someone uses the same tag, how is that making any difference than the namespaces?

  3. Squatters - they are here to stay and thrive. Whether it is on flat namespace or not it doesn’t matter. However, if you reserve the username namespace for each user, and you don’t allow multiple users, you have some chance of at least putting under some control. Both choices do not really make any difference for this, so this is 100% invalid argument.

  4. The cost of namespacing - they are bad because… you don’t like them? In this thread we still have not been presented with absolutely any reliable, non subjective, reason why namespaces are bad and what is this “cost” associated with them? Is it someone is lazy to write use ba::ba::ba::html as html? The only cost is the initial transition from flat to namespaced crates that’s it. I challenge anyone else to present me with good examples of significant costs of using namespacing, which would somehow be not present in the flat namespace.

  5. Again, if needed allow people to publish both under their username/organiszation/reserved namespace and on the flat. But please don’t take this liberty for I like it so this is what we do reason.

3 Likes

You are free to use the - character to namespace your crates under your preferred username or organization name.

Freeform namespaces aren’t really the same if you can’t reserve that prefix. I would be free to create withoutboats-foo without any input from you, whereas people can trust that you’re involved in anything under github.com/withoutboats/.

3 Likes

That’s why I think it would be good to reserver the namespaces at least per user case, so that there is something that you can trust. Still, there could be an option and to publish at the same time on the flat namespace

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.

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

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.

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.

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.

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

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

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

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

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

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.