[Merged by Bors] - Use bevy_reflect as path in case of no direct references

[YohDeadfall]

Fixes #1844

[YohDeadfall]

Did a typo which while writing the commit message, but quickly fixed it.

[alice-i-cecile]

This seems like a sensible approach.

[YohDeadfall]

@alice-i-cecile, shouldn't all approved PR get the ready for @cart tag?

[alice-i-cecile]

@alice-i-cecile, shouldn't all approved PR get the ready for @cart tag?

Standard rule of thumb is two community reviews approving it <3 This only has one still, and it's not so trivial that I think it's correct to bend that.

[mockersf]

There are other places where we use find-crate (bevy_derive & bevy_ecs/macros). Would it make sense to unify them to cargo-manifest?

[YohDeadfall]

I thought to make a follow up PR to cleanup other places to and unify the logic. It's more like a refactoring, so not included all changes here. This one for fixing the issue, another introduces a new crate and moves all path getting logic to it.

Add other changes here too?

[alice-i-cecile]

I would prefer it as one PR; it'll be easier to review that way and we don't risk forgetting.

[cart]

Add other changes here too?

Yeah I think that makes the most sense. Just do it in a separate commit so we can revert it if necessary.

[YohDeadfall]

Not a problem, but you have to manually merge it then since bors squashes them as I understand to avoid noise like fixups.

[cart]

Not a problem, but you have to manually merge it then since bors squashes them as I understand to avoid noise like fixups.

Sorry I wasn't clear enough. I meant "revent" in the context of "pre-merged pr". Once we merge I don't think we'll need that level of granularity.

[cart]

Semi-lazy question: what motivated the move from find-crate to cargo-manifest?

[YohDeadfall]

A bit better API on dependency handling. find-crate requires setting type of dependencies on the manifest to use it's find methods, while cargo-manifest represents a manifest as is, so there are two members for dependencies: dependencies and dev_dependencies.

[MinerSebas]

Please also add the new bevy_macro_utils crate to the publish.sh File in the tools Folder.

[YohDeadfall]

@MinerSebas, added, but looking on how crates depends on each other it might make sense to move the module resolution logic to bevy_utils. It shouldn't increase compilation time.

[cart]

Just refactored Manifest logic into BevyManifest. This accomplishes a few things:

1. Removes the need to import floating helper functions
2. Makes it easier to reuse Manifest import work
3. Enabled the removal of Modules from bevy_derive. Modules required extracting all bevy module info from Manifest instead of just whats needed. The new BevyManifest::get_path(BEVY_RENDER) pattern allows us to only parse the manifest once and only extract the information we need.

I also removed the as_crate attribute. I don't think it was worth the extra complexity and it had user-facing performance implications for solving a problem that only really exists in internal bevy crates. The use crate as bevy_X pattern works fine for using derive macros in the crates they are defined.

[cart]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-android
• build (nightly, ubuntu-latest)
• build (stable, macos-latest)
• build (stable, ubuntu-latest)
• build (stable, windows-latest)
• build-wasm (nightly, ubuntu-latest)
• build-wasm (stable, ubuntu-latest)
• check-doc
• check-markdown-links
• markdownlint
• run-examples