"Alternatives to" links, appearing bidirectionally

[ijackson]

Problem

I often find myself hunting through the crates.io search for a crate to solve a particular problem. Often there will be multiple possibilities, and in that case I would like to be able to find the relevant options and evaluate them side-by-side.

Currently this is quite difficult because it is difficult to find the alternatives. The very best crate authors discuss alternatives in their documentation but doing so is a lot of work, and the incentives to crate authors to do this are quite weak. So mostly I have to rely on the keyword search (or word of mouth, etc.).

Proposed solution

I have an idea for new piece of metadata from crate authors which I think they would be keen to provide, and which would help solve this problem.

I suggest a new metadata field (in Cargo.toml until #3167) something like this:

[package]
name = 'my_slotmap'
alternatives.recommended = ['slotmap`, 'std::vec::Vec']
alternatives.other = ['yet_another_linked_list']

crates.io would use this recommendation data in both directions. There would be a new section on the results page for a particular crate:

Alternatives to this crate:

Recommended by the authors of this crate:

• slotmap
• std, std::vec::Vec

Recommended by their own authors:

• super_slot_map

Other

• yet_another_linked_list

Discussion and alternatives

I haven't deeply considered the exact metadata format and feature set. Sort order and precise presentation are TBD (and we could easily experiment with those). But I have some opinions about the shape of the metadata and what is done with it:

Required features for this to be useful and useable

• A way for a crate author to get themselves listed in the alternatives section of another crate. This is what makes this an attractive thing to do even for a selfish crate author.
• A way for a crate author to distinguish things they actually recommend from things they have listed only to get the back link.

Possibly useful features

• A way for a crate author to produce only forward links. This would be a way to deprecate this crate and suggest what to use instead.
• A way to provide links to related crates, which enhance this one.

These use cases can (and often are) currently handled by the README.md and crate-level rustdocs. For those, that would be sufficient for now at least.

• Being able to point to a specific item. This is particularly useful if you want to point to the stdlib, or a part of a large suite like Tokio.

Definite non-features, ie things that should not be supported

• A way for a crate author to say nasty things about another crate, especially on that other crate's page. For this reason I suggest no free text field
• A way for a crate author to get a backward link from the other crate without also producing a forward link fromk their own crate.

[Turbo87]

The very best crate authors discuss alternatives in their documentation but doing so is a lot of work, and the incentives to crate authors to do this are quite weak.

I'm not sure that would change by listing them in the Cargo.toml file instead, especially because there it can't be explained why the own crate is better than the alternatives

[ijackson]

Tobias Bieniek writes ("Re: [rust-lang/crates.io] "Alternatives to" links, appearing bidirectionally (#3185)"):

I'm not sure that would change by listing them in the Cargo.toml file instead, especially because there it can't be explained why the own crate is better than the alternatives

The point of my idea is that crates.io would show *your* crate on the pages for the *other* crates you list. Like a targeted ad :-). That will make everyone's crate more discoverable. Ian.

…

-- Ian Jackson <[email protected]> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

[Turbo87]

Hi @ijackson! We just discussed this issue in our weekly team meeting and concluded that we would prefer it if people would solve this via PRs to other project READMEs. If we enabled people to add content to crates that they don't own that would open the door to potential abuse and we would like to avoid that.

tl;dr we decided we won't move forward with this feature request.