Closed tanvi-jagtap closed 5 months ago
Questions:
- Will
gpr_log
and friends get removed or will they remain and wrap ABSL APIs?
Yes. Removing them is the plan.
- Are there any ABSL logging features we should not use in gRPC?
Not that I know of. However @ctiller may be able to validate that.
- Will
GRPC_VERBOSITY
andGRPC_TRACE
env variables keep working?
No changes are expected to GRPC_TRACE and related functions. I will get back to you on GRPC_VERBOSITY . There are some things I need to look into.
- Is there a way to suppress the
absl::InitializeLog
warning for our users? It will force them to add dependency to ABSL to their main function and I anticipate a lot of grumbling.
I will get back on this too.
Re: suppressing the absl::InitializeLog
warning: I highly recommend not doing so. That behavior is controlled by absl, and if we introduce mechanisms over top by default then we're fighting their defaults which is going to lead to more confusion - especially since it's unallowed to call InitializeLog
twice.
Ack that there'll be some grumbling.
Re: GRPC_VERBOSITY: I'd propose we introduce some code that if it's set overrides the absl defaults -- but if it's not set we exert no opinion on what absl does.
Ack that there'll be some grumbling.
This may cause a lot of frustration with our users, i.e. people may perceive it as some real issue and end up spending time trying to figure out how to fix it, then having to add a dependency to ABSL log (and that may be challenging for people with weird build systems).
I feel like we need to be user friendly.
Questions:
gpr_log
and friends get removed or will they remain and wrap ABSL APIs?GRPC_VERBOSITY
andGRPC_TRACE
env variables keep working?absl::InitializeLog
warning for our users? It will force them to add dependency to ABSL to their main function and I anticipate a lot of grumbling.