-
Notifications
You must be signed in to change notification settings - Fork 88
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
Allow users to specify a custom path to the rust_embed crate in generated code #232
Conversation
113801b
to
f05946c
Compare
I don't understand the use case. Why doesn't changing to |
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. |
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. |
f05946c
to
0745567
Compare
…ated code
Thanks for considering this PR still -- I've rebased on main and resolved the conflicts. I noticed 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 |
fn matcher() -> ::rust_embed::utils::PathMatcher { | ||
fn matcher() -> #crate_path::utils::PathMatcher { | ||
#declare_includes | ||
#declare_excludes | ||
static PATH_MATCHER: ::std::sync::OnceLock<::rust_embed::utils::PathMatcher> = ::std::sync::OnceLock::new(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something to consider: these are the two places where we use ::rust_embed
instead of rust_embed
... was this for a particular reason?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a feeling this is just code style for this particular contributor based on the ::std
usage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding was that you should always use the ::
prefix in proc macros since it is an absolute path--it wouldn't get broken by stuff being renamed or different use
s being added under the same name, outside the macro in the end user's surrounding file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this also need to use #crate_path
to be consistent?
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 |
@pyrossh is there a possibility on getting this released to crates.io? I believe 8.4.0 does not have this in yet unfortunately. |
@mara-schulke Released v8.5.0 with these changes. |
Thanks a lot! 🌞 |
Hi @pyrossh, thanks for taking the time to maintain this crate and oversee the community's contributions 🙌
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
crate_path
attribute which allows the end-user to specify the path to the rust_embed crateNotes
crate
as the attribute name instead ofcrate_path
(just like serde does), butproc_macro_derive
did not accept 'crate' as an attribute name.