The problem of meaningless crates

community
1

There are a number of crates that do not provide any benefit, but only use the necessary names. For example:
no-std
async
Why do they exist? What would you suggest doing with them?

1 Like
2

since crates.io is not moderated, there's not much can be done about it.

crates.io has a first-come, first-serve policy on crate names. generally any name is allowd in principle. see: crates.io: Rust Package Registry

currently, external crate names must be valid rust identifiers. this issue cannot be solved, unless some form of namespacing machenism is introduced.

this is not directly aiming to solve squatting, but it might be interesting:

https://rust-lang.github.io/rfcs/3243-packages-as-optional-namespaces.html

3

no-std and async are objectively squatted and thus in violation of crates.io policy; they would presumably be removed if reported. server has both recent activity and nontrivial code, so I'm not sure why you think that's an issue.

3 Likes
4

Oh, I just couldn’t find its code on github, and so I decided that it was also empty

5

You can view the actual source code of any package using docs.rs, for example, https://docs.rs/crate/server/latest/source/. When judging a package you should trust this over GitHub, because packages can be uploaded with whatever contents the package owner chooses — there is no guaranteed relationship to any repository.

11 Likes
6

no_std is a crate name that I can see a genuine argument for stubbing it with a package containing just

// lib.rs
const () = {
  panic!("#![no_std] is a compiler builtin, not a crate");
};

to make sure nobody is using it on accident.