-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected behavior with max_level_*
in dependencies.
#309
Comments
@Benjamin-L Hmm this is a problem. Libraries shouldn't be using the I think we should call that out in the docs more. For this specific issue I think we should try get that transitive dependency to avoid using those features. |
I feel like it does sometimes make sense to have a dependency default to a particular |
Yeh, the global nature of these features is a bit of a footgun. For the system we've got now I think we should strongly recommend libraries against using the max-level features. If they're logging in paths that are hot enough for an atomic load and check to make a noticeable impact then they could provide their own wrappers for the |
It looks like the dependency in question will rework their use of the I'll go ahead and close this one now, but please feel free to re-open it if anything new comes up! |
I ran into an issue where one of my transitive dependencies set
release_max_level_error
. This meant that when I tried to specifyrelease_max_level_info
, it didn't actually do anything in either my crate or the dependency. This is both rather confusing to debug, and means that there's currently no way I can get my crate to outputinfo!
calls on release builds.In my case, it would be better to revert the ordering of which
max_level_*
features override others, os thatmax_level_info
would take priority overmax_level_error
, but I could also easily imagine a situation where this would be reversed.Because of this, I'm not sure if there's a reasonable solution.
The text was updated successfully, but these errors were encountered: