Bevy_utils should not force tracing's release_max_level_info crate feature

[shanesveller]

Bevy version

0.6.1 and current main

Operating system & version

Applicable to all

What you did

Include a direct/transitive dependency on bevy_utils, which is a dependency of most bevy_* internal crates, some of which are a literal or de facto required dependency of the top-level bevy crate.

What you expected to happen

I should be able to include my preferred level of compile-time verbosity features on the tracing crate, including something more verbose than release_max_level_info or no limit at all.

What actually happened

I am forced to use the release_max_info crate feature on tracing which sets a limit on how much verbosity I can produce in release binaries, as tracing calls and attribute macros that are lower verbosity (debug or trace in this example) are fully compiled away prior to runtime.

Additional information

As a workaround, I would need to either fork-and-patch bevy_utils, or produce a Cargo profile that mimics release profile but will not receive the effects of this tracing crate flag, which currently requires re-enabling debug_assertions. If the linked line could be converted to an on-by-default crate feature of bevy_utils that was not also rigidly enforced anywhere else in the bevy crate tree, I think I could continue to use upstream code but get the verbosity I situationally desire.

Obviously this is not a common scenario and the performance overhead of each verbosity level is observable, but I think encouraging via documentation and defaults would be preferable to choosing inflexibly for your downstream users.

[alice-i-cecile]

Seems like a sensible change. Want to make a PR?

[shanesveller]

@alice-i-cecile Sure, I'll try to take a stab at the required code changes this weekend. Would you consider the documentation additions to be required in order to merge the change?

[mockersf]

Bevy is quite opinionated on how it sets up logs, and its good that it adds that feature by default...

It would be better if it was possible to disable it though

[alice-i-cecile]

Would you consider the documentation additions to be required in order to merge the change?

Generally yes, although I'll need to examine the PR in detail (I'm not super familiar with that area of the code).

[shanesveller]

Bevy is quite opinionated on how it sets up logs, and its good that it adds that feature by default...

It would be better if it was possible to disable it though

Totally in agreement there - as a default it's a fine stance to take, but the difficulty is that tracing is approaching the point of being a foundational ecosystem crate for Rust development in general. Folks who work with Rust outside of Bevy are perhaps more accustomed to working with it / configuring it directly, as I am.

[tamasfe]

I've also run into this, right now I'm using bevy_ecs in an application which also depends on bevy_utils.

Bevy is quite opinionated on how it sets up logs, and its good that it adds that feature by default...

It would be better if it was possible to disable it though

Being opinionated in design is one thing, this however just forces the user into an optimization step that affects a lot more than Bevy itself, cannot be opted-out from, and could be achieved by the user easily as well if desired.

The log crate with the same feature even warns about this:

Libraries should avoid using the max level features because they’re global and can’t be changed once they’re set.

In #1206 it was suggested that feature flags from tracing should be reexported and this one enabled by default, however I think
tracing has become such a common library now that chances are whoever works with Bevy had already worked with it or is using it, it would be more or less pointless.

I believe the best way forward for this would be simply removing the constraint and adding an entry about it in a performance/release-oriented section of the documentation.

Alternatively if this feature flag is really desired, it could be moved up from bevy_utils to the bevy crate itself so that only the main target audience of the project would be affected.