Improve macro hygiene

[aecsocket]

No description provided.

[Shatur]

I agree with the idea of not relying on the prelude import, but not sure if it's the best way. Not very knowledgeable in macros, tho 😅

I just saw that bevy_atmosphere and leafwing-input-manager use proc_macro_crate, maybe do the same?

There is also bevy_macro_utils::BevyManifest.

What do you think?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.37%. Comparing base (a95a67c) to head (89bd15d).

Additional details and impacted files

@@           Coverage Diff           @@
##           master       #5   +/-   ##
=======================================
  Coverage   90.37%   90.37%           
=======================================
  Files          28       28           
  Lines         904      904           
=======================================
  Hits          817      817           
  Misses         87       87           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[aecsocket]

Apparently that has problems with examples: bkchr/proc-macro-crate#14

Also, I don't think this needs something that heavyweight which parses the Cargo.toml. The quote solution is relatively simple and doesn't add extra deps.

I see that bevy_reflect uses BevyManifest, although I'm not super familiar with that so I don't know how it's used.

[aecsocket]

I've changed this to:

• extern crate self as bevy_enhanced_input in lib.rs so all the unit tests compile
• add the leading :: to the macro path
  But I think, if a user uses this crate and renames bevy_enhanced_input to something else in the manifest, the derive macro will break. Not sure what to do about this.

[Shatur]

I don't think this needs something that heavyweight which parses the Cargo.toml.

Agree, it's a bit weird.

I see that bevy_reflect uses BevyManifest

It works the exact same way as proc-macro-crate.

But I think, if a user uses this crate and renames bevy_enhanced_input to something else in the manifest, the derive macro will break.

Yeah, this is what proc-macro-crate and bevy_macro_utils trying to solve. And this is why I decided to ask. I personally agree with the current PR state :)

[Shatur]

Thanks for looking into it!