New feature on lib.rs: in the footer similar crates are split into "Related" and "See also" groups.
The "Related" ones are crates that have crate owners in common or are in the same repository, and additionally to display a more relevant list they're filtered to have something else in common, like the name prefix or home page URL.
The "See also" group is just crates with similar keywords which didn't make it to the other group.
Check out the examples: serde, rand, or tokio.
Is there anything I can do to downrank things like serde_codegen_internals, serde_macros, serde_codegen from the namespace from my end? They are not things that anyone should look at in 2022+.
Some automated signals that might work:
the number of crates depending on it hasn't grown by more than 1% in the last half decade
severely outdated deps (syn 0.10...)
There were sorted by similarity. I've changed them to sort mostly by their ranking. Ranking already includes signals such as outdated deps and loss of popularity. serde_derive_internals is a tough case, because it has more traction and maintenance than an average crates-io crate 
Unfortunately, I don't have any side channel to directly deprecate crates. You can yank them. You can remove them from serde-rs repository plus optionally move them to an "archived" repo on GitHub. You can add badges.maintenance.status = "deprecated".
BTW, I've also enhanced search. Now it tries to disambiguate topics like "otp" meaning either "TOTP" or "erlang".
If you search for "http", it'll ask if you mean "http …client? …server? …async?"
Perhaps accept a bit of metadata in Cargo.toml? Another example here is time: the related crates are time-macros, time-macros-impl, time-formatting, and time-core. None of these are ever intended to be used on their own — such a use case is officially unsupported. Even then, time-macros is the only one that's active. time-macros-impl is for an old version of time and is no longer needed, and the latter two are merely reserved names for a future split into multiple crates.
Maybe this should be something official on crates-io? Perhaps a category for "internal" crates? Maybe a yank-like command that hides crates from the website?
I think a specific categories value would suit the "this is an internal crate" use case well — it's describing a purpose the crate serves.
For obsolete crates, I think it would make the most sense to publish a final version with suitable README updates ("this is no longer used since version ") along with other metadata, but people are less likely to bother to do that at all, so a yank-like mechanism might be interesting for that but I'd guess it would see less use than the other feature.
If people won't bother to publish updated metadata, what makes you think they'll bother to do some "yank-like" thing? (I sure hope you're not talking about actual yanking, that would create issues in the ecosystem for no good reason)
My reasoning is that a single command is simpler and less disruptive than preparing a new version (with bumped patch version number) to publish. I don't think it would see enough use to be worth implementing though.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.