Crates.io: Remove badges from crate lists and details

[Turbo87]

Back when badges on crates.io were introduced they were useful because there was no other way to display them. By now we render the README files for a lot of crates directly on crates.io, which often include these same badges.

In our team meeting today we decided to deprecate the badges feature. We will still keep the metadata around for now and send the data to our clients via the API, but we no longer want to display the badges on the crate list pages or the crate details page, except for the badges inside of the README files.

Specifically, https://github.com/rust-lang/crates.io/blob/master/app/components/crate-row.hbs#L14-L18 and https://github.com/rust-lang/crates.io/blob/master/app/templates/crate/version.hbs#L79-L83 need to be removed, and anything else related to it in the frontend code.

Please note that a few things will still remain as badges for now. For example, in the crates lists we currently display the latest version as a badge for some reason. Most of the other Badge components can probably be removed though.

[stanislav-tkach]

Will things like is-it-maintained-issue-resolution also be removed?

[BurntSushi]

but we no longer want to display the badges on the crate list pages or the crate details page

Would it be possible to elaborate on this? I found the badge display in search results to be pretty useful as a signal for crate quality and maintenance status.

[Turbo87]

Will things like is-it-maintained-issue-resolution also be removed?

yes, but it is totally up to the crate maintainers to add this badge to their README file instead.

but we no longer want to display the badges on the crate list pages or the crate details page

Would it be possible to elaborate on this? I found the badge display in search results to be pretty useful as a signal for crate quality and maintenance status.

While I agree that some form of quality and maintenance indicator in the search results might be useful, displaying, in some cases, up to ten different badges for each search result was making the results view quite cluttered.

The "Maintenance Badge" specifically was also quite problematic because the value was/is hardcoded in the Cargo.toml file, but when something is no longer maintained then it seems unlikely for the no-longer-maintainer to publish a new release that updates the value.

Ultimately, both the badges in general, and the "maintenance badge" in specific were creating significant busy work for the crates.io maintainers, because of the "we would like to have a badge for XYZ" and "can you manually update the maintenance status for this unmaintained crate please" requests.

We've also looked at some of the other package registries and none of them display badges anywhere other than in the README.

I personally would like to see something close to what https://npms.io/about did for the JS ecosystem. Implementing something like that will take quite a bit of time, but it might still be a good long-term goal.

I hope that answered your question sufficiently :)

[jhpratt]

FWIW I quite like badges.

With regard to maintenance, I'd prefer that weren't something in Cargo.toml, though. An option on crates.io would be preferred, still opt-in of course.

[stanislav-tkach]

Sorry for bothering, but I would like to clarify one more thing. As far as I understand, badges are deprecated on crates.io, but what is their status in cargo manifest format? Will (or should) they be deprecated there too?

[Turbo87]

@DarkEld3r They are not officially deprecated in the manifest yet, as the deprecation there would probably have to go through the RFC process. since crates.io will no longer display most of them there is not much reason to keep the data in the file though.

One exception is the "maintenance status" badge. https://github.com/rust-lang/crates.io/pull/2439 will make that badge available as an API endpoint and in the current state this badge will still be based on the info from the Cargo.toml file. Once https://github.com/rust-lang/crates.io/issues/2437 is implemented this will change, but even then I expect us to use the metadata from the file as a fallback.

I hope that answers your question :)

[stanislav-tkach]

@Turbo87 Thanks for the clarifications!