Support telling serde where it is, i.e. when re-exported as a transitive dependency. #108
Conversation
|
I don't think we should re-expert serde. We looked into this with Dropshot and decided against it. David Tolnay steered us away from it as I recall. oxidecomputer/dropshot#67 |
…ive dependency. Supported by the `serde()` annotation in derive macros, which otherwise will assume that serde is a direct crate dependency. When a macro emits a type that derives Serialize/Deserialize, the user of that macro would normally have to directly depend on serde themselves for the resulting expansion of those derive macros. This can be cumbersome when consuming serde transitively via some other crate (i.e. progenitor). https://github.com/serde-rs/serde/blob/5a8dcac2ed1407fab3f7fd23f2d56af42dcd448f/serde_derive/src/internals/attr.rs#L556-L561
lifning
force-pushed
the
serdesisawendys
branch
from
2533b2f
to
329b19b
Compare
I see, though I imagine the situation for progenitor output might be different with regard to the concern about it being onerous and error-prone to include that attribute for every serde derive, being that it's automatically generated. Is it something we'd still be uncomfortable using here for other reasons? |
Yes, agreed.
I guess I'm unclear on the problem we're seeking to address. |
Supported by the
serde()annotation in derive macros, which otherwise will assume that serde is a direct crate dependency. When a macro emits a type that derives Serialize/Deserialize, the user of that macro would normally have to directly depend on serde themselves for the resulting expansion of those derive macros. This can be cumbersome when consuming serde transitively via some other crate (i.e. progenitor).https://github.com/serde-rs/serde/blob/5a8dcac2ed1407fab3f7fd23f2d56af42dcd448f/serde_derive/src/internals/attr.rs#L556-L561