Pre-RFC: related crates metadata field

there's been several proposals to try to alleviate the poor discovery of crates, so here's yet another, this time leveraging backlinks.

this would add a new metadata field along with "categories" and "keywords": package.related. this is yet another list of strings, although this time they would be identifiers for packages. they could be urls or package names, but would only accept names that refer to uploaded packages, similar to how it rejects git dependancies.

on a crate page, there would be a list of all crates that specify it as a related package, similar to how the list of dependancies work.

to try to mitigate spam potential, there would be a limit of 3 "related" crates on published crate.

the primary usecase is to specify possible alternative implementations, to allow developers to properly weigh their options.

I would suggest splitting off suggestion of crates that can be used with the current crate (complimentary crates) and crates that can be used instead of the current crate (alternative crates)

So pin-project would add pin-project-lite as an alternative crate, while nalgebra would add simbaas a complimentary crate.

But the real problem with embedding crate metadata in Cargo.toml is that it's only updated when a new crate version is released. So maybe this works better if there is an alternative API to update crate metadata in that doesn't require a new crate release.


i mean, this is actually a general issue with the rust ecosystem, and applies to other things like documentation and the README file of crates.

one possibility would be adopting 4-point semver, with the last point strictly for documentation and metadata changes.

There very much is a need for mutable metadata for crates. We talked a little about this in This Development-cycle in Cargo: 1.78 | Inside Rust Blog

The issue for this is Look into ways to decouple some crate metadata from `Cargo.toml` · Issue #3167 · rust-lang/ · GitHub


A somewhat related RFC is `recommended-bin-packages` field in `Cargo.toml` by not-my-profile · Pull Request #3383 · rust-lang/rfcs · GitHub though we were thinking that a [diagnostics] table would be a better way of handling that case.

1 Like

In that case the [diagnostics] namespace was appropriate because the information was supposed to be used primarily in cargo install error messages (even though sites like and would probably display it too). But when there isn't a Cargo diagnostic that display the given information, using that namespace seems a bit odd

On the other hand, grouping all kinds of recommended crates in a single namespace is probably useful for discoverability and organization of Cargo.toml