Allow users to specify a custom path to the rust_embed crate in generated code

[Wulf]

trafficstars

Hi @pyrossh, thanks for taking the time to maintain this crate and oversee the community's contributions :raised_hands:

I'd like to request this feature: allow end users to specify a custom path to the rust_embed crate (in case rust_embed is not in-scope, for whatever reason).

Changes

• Added a crate_path attribute which allows the end-user to specify the path to the rust_embed crate

  #[derive(custom::path::rust_embed::RustEmbed)]
  #[crate_path = "custom::path::rust_embed"] // <--
  #[folder = "examples/public/"]
  struct Asset;
  

• Added a test to make sure this doesn't break in the future :)

Notes

• I tried to use crate as the attribute name instead of crate_path (just like serde does), but proc_macro_derive did not accept 'crate' as an attribute name.

[AzureMarker]

I don't understand the use case. Why doesn't changing to ::rust_embed work? That's the recommended approach to the problem of when users rename a crate. See for example https://users.rust-lang.org/t/how-to-unambiguously-refer-to-a-particular-crate-from-a-proc-macro/39061. I don't think the current approach should be merged.

[Wulf]

hey @AzureMarker, hope all is well. Thanks for the review :)

The use case here is to allow end-users to re-export the crate for use in another crate. This is useful in dependency management -- imagine adding rust_embed to several helper crates compared to just adding it to a single common crate that helper crates can depend on. Here's how it's currently done in serde. Let me know if I can clarify or if there's another approach you'd prefer.

[AzureMarker]

I see, thanks for clarifying. Personally I would use the workspace dependencies feature instead (https://doc.rust-lang.org/cargo/reference/workspaces.html#the-dependencies-table), but I understand that re-exporting has some other advantages and also works outside of a single workspace.

The changes look fine, but I'll also ask @pyrossh to approve since it's a new feature.

[pyrossh]

@Wulf It is possible for you to try out using workspaces assuming you don't need to do much refactor? For example this is how zed have done it.

But anyways the change is pretty small and doesn't seem to break anything so can merge it. Let me know.

[Wulf]

Thanks for considering this PR still -- I've rebased on main and resolved the conflicts. I noticed cargo test --release is broken on master (edit: just checked again, this is nothing major, just some doc code failing tests).

I'd like to add that I'm not able to just use workspaces to manage deps because this feature is being used in a downstream library crate which doesn't impose project setup details on end users.

Please do merge this in @pyrossh

[mara-schulke]

Just for documentation purposes: This PR saved us a ton of work. Thank you so much!

This attr is super useful as we want to use rust_embed within a sdk and do not want our users to add rust_embed as dependency directly, but rather use our reexport!

[mara-schulke]

@pyrossh is there a possibility on getting this released to crates.io? I believe 8.4.0 does not have this in yet unfortunately.

[pyrossh]

@mara-schulke Released v8.5.0 with these changes.

[mara-schulke]

Thanks a lot! 🌞