Skip to content
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

how to reexport Serialize, Deserialize? #1465

Closed
woodgear opened this issue Jan 29, 2019 · 16 comments
Closed

how to reexport Serialize, Deserialize? #1465

woodgear opened this issue Jan 29, 2019 · 16 comments

Comments

@woodgear
Copy link

just like this question
#856 (comment)

My use case is slightly different. I have a project set up as a Cargo workspace, and I am thinking about setting up an internal common crate to handle external dependencies shared by multiple internal crates. serde and serde_derive are some of those crates I'd like to share.
With the proc_macro feature, I can easily put the Deserialize/Serialize macros in scope wherever I need them. However, if I do so outside the common crate, I get the error in the issue title.
I haven't looked into the internal workings of these macros at all, but I'm guessing they are looking for ::serde (or maybe $crate::serde) in scope. However, in my case serde will be at ::common::serde. Is there any way I can work around this?

the common crate

//lib.rs
#[macro_use]
pub extern crate serde;
pub extern crate serde_json;
pub use serde::{Serialize,Deserialize};//for reexport macro
[dependencies]
serde = { version = "1.*" ,features = ["derive"]}

the main crate who want to use serde from common ccrate

//main.rs
#[macro_use]
extern crate common;
#[derive(Serialize)]
struct Test {

}
fn main() {
    println!("Hello, world!");
}
[dependencies]
common = { path = "../common" }

it should be work but always report error like

error[E0463]: can't find crate for `_serde`
 --> src\main.rs:5:10
  |
5 | #[derive(Serialize)]
  |          ^^^^^^^^^ can't find crate

how should i do that?

@dtolnay
Copy link
Member

dtolnay commented Jan 29, 2019

There is no supported way to do this currently. The downstream crate will need to add its own dependency on serde.

If it is an absolute requirement that this work, then you could fork serde_derive and modify it to emit paths that refer to common::serde everywhere instead of serde.

@woodgear woodgear reopened this Jan 29, 2019
@woodgear
Copy link
Author

I am confusing why it is impossible. could you please give me some explain or I am lose some extra information?

@dtolnay
Copy link
Member

dtolnay commented Jan 29, 2019

The code emitted by serde_derive would look something like:

impl serde::Serialize for Test {...

But if there is no such thing as serde in the main crate, then this code does not compile.

@woodgear
Copy link
Author

so we need some way to make serde been visible in the main crate. is that exactly what use should do?

@dtolnay
Copy link
Member

dtolnay commented Jan 29, 2019

All that's needed is for the main crate to add a dependency on Serde.

[dependencies]
serde = "1.0"

From there, the derived code will find it.

@woodgear
Copy link
Author

woodgear commented Jan 29, 2019

i know. yes, of course, i could do that, but i think it should not do. i am confusing why we have no ability to do. it seems rust could not use other crate's depended crate, right?

@photex
Copy link

photex commented Jul 3, 2019

I have a very large repo/workspace at work. Many crates have to have their own serde line in the Cargo.toml now and it's going to potentially be a bit of a chore someday in the future. We already have a utils crate that re-exports common cli and logging setup. We have another for grouping common dependencies for certain tasks.
It would be very helpful for Serde to work correctly when re-exported as well.

@thedavidmeister
Copy link

this is painful for us, we have several repos with a few dozen crates and every time we want to do something with the serde dependencies it is a tedious hunt to go find all the places it is being used

@thedavidmeister
Copy link

@woodgear why did you close this, it seems unresolved?

@AgarwalPragy
Copy link

Sorry to bother, is there any update on this?

My usecase is the same as OP

@Cightline
Copy link

I have the same issue as the last few posters.

@xixixao
Copy link

xixixao commented Jan 3, 2021

Based on yewstack/yew#1454 looks like this is fixable now with crate::* on stable.

@lastmjs
Copy link

lastmjs commented Mar 13, 2021

So how is this fixable? I'm trying to get it to work, but not having luck

@dman-os
Copy link

dman-os commented Mar 15, 2021

Has anybody found a way around this?

@dman-os
Copy link

dman-os commented Mar 16, 2021

For anyone looking, I've found a way around this using a derive helper attribute that serde implements (here; couldn't find where it's documented).

Usage:

use common::serde::{self, Deserialize, Serialize}

#[derive(Copy, Clone, Debug, Deserialize, Serialize)]
#[serde(crate = "self::serde")] // must be below the derive attribute
struct Vertex {
    position: [u32; 3],
}

@lastmjs
Copy link

lastmjs commented Mar 25, 2021

The above worked for me! Thank you!

@serde-rs serde-rs locked and limited conversation to collaborators Aug 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

9 participants