Conditionally init of global logger when tracing-log
feature is enabled
#3075
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Solves #3074
Solution
I want to gather some feedback before putting more work into this PR.
There is a standard trait implementation of
SubscriberInitExt
. I cannot use a builder pattern for persisting the flag to signal whether a global logger should be initialized or not because I cannot introduce any trait fields.My workaround is to add a feature gated parameter to
init
andtry_init
to then conditionally set the global logger.I am not sure if you are OK with having feature gated parameters and with such a breaking change.
Regarding the update of the init methods I feel it is a good decision to give (and also enforce) more fine grained control during runtime. I have seen bugs in other repos where people were pulling in
tracing-subscriber
without being aware of the consequences (of having a global logger set) whentracing-log
is enabled by default. Normally you would only havetracing-subscriber
down the stream when letting another lib manage your tracing init logic. For such scenarios it makes sense to throw compile time errors in case that specific lib does not support the feature gatedwith_logger
parameter. Imho that is better than unexpected behavior in terms of silently tracing logs.Another alternative could be a new method which then does not prevent existing users from thinking more about the impact of the default behavior
fn try_init_with(self, set_logger: bool)