-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forced serde_derive dependency #5
Comments
Thanks for the issue, and I think that is a good solution. I'll keep this open until the SO issue is resolved and I update this crate. Another workaround (definitely not ideal) for your setup would be to copy the |
A workaround would be to add a #[derive(Serialize_tuple)]
#[serde_tuple(crate = "serde")]
struct SomeStruct; |
@jean-airoldie I think that is a good idea, but I think the name Actually, it looks like your initial suggestion (depend on serde with the Looking back, I'm not sure why this crate was depending on |
The master branch works for me currently. Should we close this? |
@jean-airoldie Great! I just went ahead and updated the syn/quote/proc-macro2 dependencies to their I'll close this now, but let me know if anything doesn't work, |
Using this crate alongside a
serde = { version = "1.0", features = ['derive'] }
dependency causes behavior like in #2. This is due to this line that assumes thatserde_derive
is present. However it cannot be replaced byserde::Serialize
since this causes serde-rs/serde#1467 caused by rust-lang/rust#55779.A sketchy work around is to define a
in the same module where
Serialize_tuple
is used.I think that once rust-lang/rust#55779 is fixed, this crate should depend on
serde = { version = "1.0", features = ['derive'] }
since, from what I understand, feature flags forces the dependency down the chain, while simply depending onserde_derive
(like this crate does currently) does not.The text was updated successfully, but these errors were encountered: