Category for *-derive crates

tools and infrastructure
1

It's common that when a crate uses custom derive macros, the developer also publishes a *-derive crate, and re-export the derive macros in the main crate.

However, what category should those *-derive crates belong to? crates.io has a list of categories, but I don't think there is an appropriate category for those crates.

For example:

  • serde has no-std::no-alloc, no-std, encoding

    serde_derive has no-std and no-std::no-alloc

  • clap has command-line-interface

    clap_derive has command-line-interface and development-tools::procedure-macro-helpers

  • bevy has gui, graphics, game-engines, rendering`

    bevy_derive has no categories

For common *-derive crates, the category development-tools::procedure-macro-helpers should not be a great place, since it is for "crates to help you write procedural macros in Rust", e.g. syn or darling.

Should there be an independent category for those *-derive crates?

4 Likes
2

These crates are part of the main library, and I see no reason why they should have a different category than the main crate.

1 Like
3

Alternately, perhaps “no category” is appropriate, since you’re not intended to use the -derive crate independently, and thus don’t need to make it discoverable.

4 Likes
4

I think it would make sense to have a category for these crates which marks them as not intended for direct use. This category could then be used to make them less discoverable by ranking them lower.

16 Likes
5

"Internal crate" category would be useful.

There are also many -core, -types, -util, -src and so on crates that projects document as not for external use, not their stable API.

4 Likes
6

I agree that we should have a "internal crate" category. Should there be a standard field in Cargo.toml for those internal crate to point to one or more "main crates"? e.g. serde for serde_derive. By doing so, cargo could warn users that they are using an "internal crate", and provide hints of what "main crate" should be. Or should we just encourage the developers to write it in README?

7

It would actually be better to use serde and serde_derive separately, it leads to less bottlenecking in the build typically. Very often everything is waiting on serde to build at some point, reducing parallelism. You want wide dependency chains rather than deep.

8

For the serde specifically, they seems to encourage using serde_core to speedup building.

So the question is that shall we use the *-derive crates or using re-exports in main crates? The proposed "internal crates" category will encourage users to use main crates only.

9

(And you can’t use serde_derive without serde because serde_derive generates code that references serde, or at least serde_core.)

10

Can't this be solved at Cargo itself? It does not need to build anything in order to determine that serde_derive is also a requirement...