serde-rs / serde

Serialization framework for Rust
https://serde.rs/
Apache License 2.0
9.06k stars 767 forks source link

Make serde-derive's implicit peer dependency on serde optional #1147

Open killercup opened 6 years ago

killercup commented 6 years ago

So, I have a very weird request. I'm trying to re-export serde-derive in my quicli crate, but since this code

https://github.com/serde-rs/serde/blob/1bdf5ecec40ae9d4b77b321341a4f5c9cd4cb6ba/serde_derive/src/de.rs#L63-L69

expands to extern crate serde as _serde, my consumers would have to add serde to their dependencies—which I want to avoid (the selling point of the crate is to only add it as dependency). Is there another option of doing this? E.g., making this part of the derive optional (with a feature flag)?

cc https://github.com/killercup/quicli/issues/9

oli-obk commented 6 years ago

E.g., making this part of the derive optional (with a feature flag)?

Not really. If there's a crate that depends on serde_derive and has the feature flag activated (and your users depend on it), it will be back on, and the users of your crate will again get compilation failures

killercup commented 6 years ago

Hm, true. That's really unfortunate, though. I'd love to do this in some way that isn't "fork every proc macro and change stuff to extern crate quicli as serde_;… Do you have any other ideas?

oli-obk commented 6 years ago

Maybe serde_derive can reexport serde and then do use ::serde_derive::_serde;? It's not like it makes any sense to have serde_derive without serde.

killercup commented 6 years ago

That would be a pretty good solution. But… Wasn't there some reason not to do that? Can you access proc_macro crates' items like that?

Am 22.01.2018 um 11:34 schrieb Oliver Schneider notifications@github.com:

Maybe serde_derive can reexport serde and then do use ::serde_derive::_serde;? It's not like it makes any sense to have serde_derive without serde.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

dtolnay commented 6 years ago

I agree we need a better story here. The url folks want this as well for a slightly different reason -- in their case we would want the macro to refer to serde1::... because serde::... means Serde 0.8 in their codebase. https://github.com/servo/rust-url/pull/327

I expect it will be tricky but perhaps not impossible to have serde_derive re-export and refer to serde. The trouble is serde already optionally re-exports serde_derive and that would be broken by a circular dependency.

c410-f3r commented 5 years ago

Sorry for bothering. Is there any news about this issue?

jean-airoldie commented 4 years ago

Perhaps a helper attribute could be added to optionally specify the identifier for the serde crate?

use serde as panini;

#[derive(Serialize, Deserialize)]
#[serde(import = "panini")]
struct Key(i32);

The proc_macro would then retrieve the import identifier an use #import instead of _serde.

dtolnay commented 4 years ago

That's implemented as #[serde(crate = "panini")].