Re-exporting a trait with a custom derive_macro

help
1

I'm writing a library that uses trait Bar from crate foo. I'm trying to re-export Bar in my crate, so users can use my library without adding foo to their cargo.toml.

Unfortunatlely, the derive macro for the trait uses the fully qualified path ::foo::Bar, so to derive it the user still needs to add the dependency.

I have written a new derive macro that uses ::my_library::Bar instead, but now I cannot export it, because the name conflicts with the original macro.

Is there a standard way to approach this problem, or are my users forced to depend on the other crate to use the trait?

2

Maybe the foo::Bar macro already implements a way to change the crate name used in the generated code? Like tokio::main does, for example? Then you don't need your own derive macro. If not, most likely (as I understand your description) foo::Bar is a re-export of foo_derive::Bar. These re-exports are often feature-gated (e.g. serde's derive feature). If you provide your own Bar derive macro, I don't see why you should also export foo::Bar. Disabling the feature of foo would resolve the name conflict.[1]

  1. If you need the Bar macro internally in your crate, you can still import it directly from foo_derive. ↩ī¸Ž

3

Thanks for the help. I did not realize that the macro was behind a feature flag, but I double checked after your comment, and it was. In case you are interested the trait was this one.

So, I guess the standard approach to keep derive macros behind a feature flag, right?

4

Yes, I'd say re-exporting derive macros behind a feature flag is idiomatic API design. Compiling proc-macro crates is quite expensive, mostly due to syn. Users that don't need the macro and are conscious about compile times will appreciate being able to opt out of having to compile the unused proc-macro crate.