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

[killercup]

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

serde/serde_derive/src/de.rs

Lines 63 to 69 in 1bdf5ec

	let generated = quote! {
	#[allow(non_upper_case_globals, unused_attributes, unused_qualifications)]
	const #dummy_const: () = {
	extern crate serde as _serde;
	#impl_block
	};
	};

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 killercup/quicli#9

[oli-obk]

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]

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]

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]

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 ***@***.***>: 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]

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. servo/rust-url#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]

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

[jean-airoldie]

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]

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