Adds user-definable log formatting#3778
Adds user-definable log formatting#3778SonicZentropy wants to merge 3 commits intobevyengine:mainfrom
Conversation
|
Post-CI I'm not sure this is even worth draft status at the moment. It seems wasm and android builds both add required trait bounds on anything holding a Subscriber that enter the HRTB territory, which is fascinating but pretty beyond me at this point and perhaps better left to collect cobwebs until I understand what's going on better |
366d467 to
d8c205b
Compare
|
Nevermind, found a better way, seems to work fine now! |
|
I wonder how this potentially interacts with the Could be a bit of a footgun if defining a custom logging format prevents you from profiling your code in the future. I'm not really familiar enough with tracing to say. I just want to point out another PR that touches this code here: #3583. |
|
You actually were completely correct about that @rparrett, though I didn't see this until I just stumbled across it in use. I stuck my head into tokio's Discord and had them help me modify it to a more proper version. This one should take care of those issues |
| /// # use bevy_app::App; | ||
| /// # use bevy_log::LogSettings; | ||
| /// # use bevy_utils::tracing::Level; | ||
| /// # use bevy_utils::tracing::{ Level }; |
There was a problem hiding this comment.
this looks like something that was part of an experiment and you didn't revert back completely?
There was a problem hiding this comment.
Yes, sorry about the delay, honestly forgot this PR existed after a while. That was probably my global config clashing and me not noticing, sorry
|
I missed the super basic formatting problem and this didn't get merged, apologies. Looks like it has a conflict now, so I'll try to resolve it this weekend since I'm sure it'll be minor |
| /// # use bevy_app::App; | ||
| /// # use bevy_log::LogSettings; | ||
| /// # use bevy_utils::tracing::Level; | ||
| /// # use bevy_utils::tracing::{ Level }; |
There was a problem hiding this comment.
| /// # use bevy_utils::tracing::{ Level }; | |
| /// # use bevy_utils::tracing::Level; |
|
@SonicZentropy I'd like to merge this :) While you're rebasing, there's a tiny formatting suggestion for the doc example too. |
|
It would be great if we allowed our users to pass not just 1 layer but multiple ones. Or we maybe could allow passing a custom subscriber, like it was done in the initial attempt, I'm curious what was the problem exactly with that one. |
# Objective Adopted bevyengine#3778. This pr allows to configure how the bevy log is formatted. The default bevy log can be a bit verbose for some projects, specially the timestamp. The objective is to allow developers to select the format that best suits them. ``` Example of original bevy log: 2023-04-13T14:19:53.674653Z INFO bevy_render::renderer: [important text!] ``` ## Solution Using `tracing_subscriber::fmt::Subscriber`, adds the attribute `layer` to `LogPlugin`. This allows to pass a `tracing_subscriber::fmt::Layer` when creating the plugin and modifying the output. For example this ```rust App::new() .add_plugins(DefaultPlugins.set(bevy::log::LogPlugin { layer: Box::new(|| Box::new(bevy::log::tracing_subscriber::fmt::layer().pretty().without_time())) ..default() })) .run() ``` prints ``` INFO bevy_render::renderer: [important text!] ``` The main idea comes from @SonicZentropy and their pull request bevyengine#3778, but it was stale since may. This has all the changes and a fix since now `LogSettings` are included in the plugin and not in a resource. Since plugin builders are stateless and not mutable (bevyengine#8101), the old solution of using an `Option<Box<Layer>>` no longer works. One solution to fix this is to use a `Box<Fn() -> Box<Layer>>`. I am unaware of another more idiomatic fix, so if you have something better please revise it. Should plugins builders be mutable in the future, this can be changed back to the original approach. --- ## Changelog - Adds field `layer` to `LogPlugin` that takes a function returning a `tracing_subscriber` custom layer. - Reexports `tracing_subscriber` from log so it can be used to configure the plugin. - Modifies the `logs.rs` and `system_piping.rs` examples to include the new configuration. ## Migration Guide No breaking changes
# Objective Adopted bevyengine#3778. This pr allows to configure how the bevy log is formatted. The default bevy log can be a bit verbose for some projects, specially the timestamp. The objective is to allow developers to select the format that best suits them. ``` Example of original bevy log: 2023-04-13T14:19:53.674653Z INFO bevy_render::renderer: [important text!] ``` ## Solution Using `tracing_subscriber::fmt::Subscriber`, adds the attribute `layer` to `LogPlugin`. This allows to pass a `tracing_subscriber::fmt::Layer` when creating the plugin and modifying the output. For example this ```rust App::new() .add_plugins(DefaultPlugins.set(bevy::log::LogPlugin { layer: Box::new(|| Box::new(bevy::log::tracing_subscriber::fmt::layer().pretty().without_time())) ..default() })) .run() ``` prints ``` INFO bevy_render::renderer: [important text!] ``` The main idea comes from @SonicZentropy and their pull request bevyengine#3778, but it was stale since may. This has all the changes and a fix since now `LogSettings` are included in the plugin and not in a resource. Since plugin builders are stateless and not mutable (bevyengine#8101), the old solution of using an `Option<Box<Layer>>` no longer works. One solution to fix this is to use a `Box<Fn() -> Box<Layer>>`. I am unaware of another more idiomatic fix, so if you have something better please revise it. Should plugins builders be mutable in the future, this can be changed back to the original approach. --- ## Changelog - Adds field `layer` to `LogPlugin` that takes a function returning a `tracing_subscriber` custom layer. - Reexports `tracing_subscriber` from log so it can be used to configure the plugin. - Modifies the `logs.rs` and `system_piping.rs` examples to include the new configuration. ## Migration Guide No breaking changes
|
I believe the functionality from this PR has already been added in other later changes. Is there a reason to keep it open? |
Objective
Solution