Please provide `proc-macro` for libraries that re-exporting this library

Line 130 in 1ecacab

fn crate_access() -> syn::Result<proc_macro2::Ident> {

is buggy since bkchr/proc-macro-crate#34, however we can solve it with

use scale_info::scale::Encode;

#[derive(Encode)]
#[serde(crate = scale_info::scale)]
struct Foo;

but this addition line is a bit verbose and ugly indeed, so maybe we can provide a proc-macro inside this repo to do the re-exporting job otherwise each of the libraries want to re-export this library will be buggy with the derive feature in some ways, they re-exported and they didn't, most of the users will import the-long-name-parity-scale-codec again

//! scale_info/src/lib.rs
scale::re_export!(); // doing the wrapping job for derive macros inside `parity-scale-codec` with the public re-exported path in this library

scale::re_export!();

Not sure how this should work.

scale::re_export!(); 
Not sure how this should work.

hmmm, after rethinking about it, my solution is buggy while users renaming the libraries that re-exporting codec, but it suits the short name libraries like scale_info, sp_runtime

just appending crate = env!("CARGO_CRATE_NAME") to the codec attribute in a new macro

//! scale_info/src/lib.rs
extern crate parity_scale_codec as scale;

// before
pub use codec::Encode

// after
//
// #[derive(scale_info::Encode)]
// struct Foo;
//
// equals
//
// #[derive(parity_scale_codec::Encode)]
// #[codec(crate = scale_info::scale)]
// struct Foo;
parity_scale_codec::generate_new_encode!()
pub use scale_info::Encode;

libaries that re-exporting parity_scale_codec can write these code themselves easily, but considering if each of the librarires implmenting this logic again and again, using an official implementation from parity-scale-codec would be proper

also, I'm trying to figure out if it is possible passing some arguments or environment variables to dep-parity-scale-codec about which crate_path of parity-scale-codec should it use for generating the derived code

https://doc.rust-lang.org/cargo/reference/build-scripts.html#overriding-build-scripts

parity-scale-codec/derive/src/utils.rs

Line 133 in 1ecacab

const DEF_CRATE: &str = "parity-scale-codec";

const DEF_CRATE: &[&str] = &["parity-scale-codec", env!("WRAPPED_SCALE_CODEC_CRATE_PATH")]; 
// ...

I don't have seen any rust crate supporting this.

The cleanest solution is this:

#[derive(Encode)]
#[codec(crate = path::to::scale::codec)]
struct Something;

Then someone could provide some kind of fake Encode derive macro that is re-exported from their crate that puts then the correct attribute with the path to the crate. However, I'm not sure that is a good way. We should just not re-export the entire scale codec crate somewhere.

I don't have seen any rust crate supporting this.

The cleanest solution is this:
#[derive(Encode)]
#[codec(crate = path::to::scale::codec)]
struct Something;
Then someone could provide some kind of fake Encode derive macro that is re-exported from their crate that puts then the correct attribute with the path to the crate. However, I'm not sure that is a good way. We should just not re-export the entire scale codec crate somewhere.

make sense, #[codec(crate = xx)] is well designed tbh, but somehow handling the package name of parity-scale-codec is insane

We should just not re-export the entire scale codec crate somewhere.

haha yeah, the less we want, the better lives we'll have lmao

I'll just close this issue since the workspace related problem is not original caused by this repo