Adds bevy_tracing crate

[mnmaita]

Objective

• Related to Remove or shrink bevy_utils #11478

Solution

• Added a new crate called bevy_tracing with all tracing utilities that were present in bevy_utils.

TODO:

We should decide if we:

a) decide to make this a breaking change and remove these utilities from bevy_utils in a follow-up or
b) deprecate the utilities in bevy_utils and migrate crate by crate to reduce diff footprint in subsequent PRs. We would need to remove the utilities from bevy_utils at some point though.

We also need to reserve the crate name in crates.io.

---

Migration Guide

• TBD

[alice-i-cecile]

My preference is for b here. I do like doing this though.

[mockersf]

I think this will contribute to the crate inflation and the feeling of "way too many dependencies" without any actual benefits

[BD103]

Can this just be moved to bevy_log instead? (Maybe behind a feature gate, or in a utilities module?) I feel like both crates overlap too much for them to be made separate.

Furthermore, the benefits provided by info, error, once, detailed_trace, and more are limited in my opinion. I don't feel like I would use them if it involved pulling in an extra crate.

[hymm]

I think the problem with bevy_log is that it'll create a circular dependency. bevy_ecs needs the tracing macros, but bevy_log needs bevy_app which uses bevy_ecs. We could make bevy_ecs depend directly on the tracing crate again if we want to go in this direction.

[mockersf]

this seems to have three different things:

• once! macro and its per level friends: could we check if the tracing crate would be interested in having them?
• detailed_trace! macro (added in [Merged by Bors] - Introduce detailed_trace macro, use in TrackedRenderPass #7639): in my opinion this one is just bad design, and it gives us two features to control the same thing. it should be removed
• info, warn, ... functions (added in Add system.map(...) for transforming the output of a system #8526). in my experience they are only here to confuse me when I want to import the logging macro with the same name, could we remove them? if we want to keep them they could go into bevy_ecs as they're supposed to be system adapters and not general logging functions

[mnmaita]

this seems to have three different things:

• once! macro and its per level friends: could we check if the tracing crate would be interested in having them?
• detailed_trace! macro (added in [Merged by Bors] - Introduce detailed_trace macro, use in TrackedRenderPass #7639): in my opinion this one is just bad design, and it gives us two features to control the same thing. it should be removed
• info, warn, ... functions (added in Add system.map(...) for transforming the output of a system #8526). in my experience they are only here to confuse me when I want to import the logging macro with the same name, could we remove them? if we want to keep them they could go into bevy_ecs as they're supposed to be system adapters and not general logging functions

I'm writing an issue in the tracing repo right now. Regarding the other points, I'm 100% in removing code that is badly designed and/or redundant. I can create a separate PR removing these and documenting the breaking changes. Wondering if we're ok with the potential overhead that removing detailed_trace would reintroduce as per the linked PR.