Create bevy_debug crate

[pablo-lua]

What problem does this solve or what need does it fill?

With the start of the bevy_editor prototype, it has become an important discussion to address the issue of what is needed to move forward with this project.
Most people agree that to do this, we need several debugging tools so that the user can enjoy a complete editing system.
However, another issue in this regard deserves discussion: Should we create a crate just for these debug tools, so that they are all housed in a separate block?
The advantages of this type of approach are numerous: If someone does not need such tools, we can disable everything as easily as disable a feature, in addition, the nesting of these tools will help in understanding the code in the future
So, as advantages, this feature would provide:

• Nesting of debug tools for easy deactivation/activation
• Management of these tools by new contributors made easier
• Making it easier to visualize what we still need for the new editor

What solution would you like?

The creation of the bevy_debug crate (or similar) for the purpose of storing those tools and the moving of all debugs tools already existent in the engine (this last part is not very necessary: We would probably have to define what is only a debug tool and what is not for this purpose)

What alternative(s) have you considered?

We can simply have a debug mod in all crates for the purpose of storing the debug tools of that said crate there
The problem with this approach would probably be debug tools that are of interest of multiple crates: Where to store this kind of tool?

Additional context

Useful discussion on this issue.

The proposal of the new editor prototyping.

[alice-i-cecile]

The other main advantages that I see are:

1. It becomes very easy to disable these in production games: simply turn off a feature flag in your build.
2. We can create abstractions (input mapping, dev console) that can be shared across debug tools.

[matiqo15]

I believe we can use bevy_diagnostic for this.

[alice-i-cecile]

IMO bevy_diagnostic is much better suited as a lightweight crate for computing diagnostics. Then, users who want to run Bevy headless (or with just bevy_app) can pull it in easily.

You do have a point though. If only we had crate docs explaining the purpose of the crate 😅

[matiqo15]

Okay, I get the idea, if we create a bevy_debug crate, we should consider moving bevy_log into it. I'm not sure if this wouldn't create some issues, but having two crates named similarly isn't a good idea.

[alice-i-cecile]

Yeah, bevy_log and bevy_diagnostics are confusingly similar already.

[mockersf]

Okay, I get the idea, if we create a bevy_debug crate, we should consider moving bevy_log into it. I'm not sure if this wouldn't create some issues, but having two crates named similarly isn't a good idea.

then we should find another name for this bevy_debug. bevy_log is different than what is intended here and is a very good name for what it is

[alice-i-cecile]

Ideas:
-bevy_debug_tools
-bevy_dev_tools

[pablo-lua]

but having two crates named similarly isn't a good idea.

Is log that much of similar with debug? IMO they are not so confusing, one is logging information about something (telling us amount of know info), the other is for identifying the info that we need and don't yet know.

But bevy_dev_tools is a good name though

[alice-i-cecile]

https://crates.io/crates/bevy_dev_tools

Crate reserved. @cart, let me know how and when you want me to transfer ownership over. My kingdom for namespaces.