Pretty much just the title. I've never once cared about what a crate has as dev dependencies, as they're not downloaded by me (only if you're doing development). Imo displaying them on crates.io serves no purpose, and may even be harmful if someone doesn't know what the difference between a normal and dev dependency is — they could be turned away from a better crate because they think it's too heavy.
8 Likes
It's useful information for crate discovery, so you can see that something that's almost always a dev-dep, like serde-test, has a lot of users.
3 Likes
It's also useful for being able to ascertain a particular crate's testing strategy at-a-glance, which is useful when comparing crates in domains that benefit from significant testing (e.g. cryptography)
2 Likes
While that definitely makes sense on its own, I will say that I've never heard of serde-test, and I have written test code for manual serde implementations. So anecdotally, I've got to note that I've never found them useful for discovering new things.
I'd say it's useful when you want to contribute to the crate. In that case, you surely want to run the tests, and/or create test cases for new features or bug fixes you implemented, using the same system the crate already depends on.
1 Like
If someone is contributing to a crate, surely they're capable of just opening Cargo.toml to find that out? They'd already have the source cloned locally, of course.
1 Like
I do think it would be a little weird if dev-deps showed up in the “dependent crates” pages but then the dev-deps didn’t show up when you actually navigate to the dependent crate. You could remove dev-deps from dependent crate lists, but that would deprive a lot of crates like serde-test from visibility of usage.
I think it would be good to indicate that a dependency is a dev dep on the "dependent crates" list. Iirc I filed an issue about that a while back.