[Question] Configuring loguru in a library that pre-configure main logger (hashtag656)

[vikramsubramanian]

I have a use case of deploying many microservices on multiple cloud provider environments (gcp, aws, azure)

Some of those Cloud Providers requires your applications to format logs in such a way so that it can be parsed automatically by other services. For example, Error Reporting in GCP requires a [dedicated structure]( of logs to group exceptions and stacktraces.

I was wondering how to configure loguru's logger in that case.

1. Should I create a library that contains only format functions and let each microservice configure it's own instance of loguru.logger?

2. Should I preconfigure inside the library itself loguru.logger and import it directly in the apps? If so, were do I import it? In the root module __init__?

I am more likely to go for solution 2. but advices would be awesome!

I read both the [README]( and the [docs]( but I couldn't find an answer for this. If you find this use case interesting, I am more than happy to add it to the docs afterwards!

[vikramsubramanian]

I went really straight to the point but solution 2 looks pretty elegant I guess:

Library side

![image](

App side

![image](

[vikramsubramanian]

Hey

Usually I advise against configuring the logger from within a library. The idea is that the end user is the one who chooses how the logging messages should be handled.

Typically, I would say that your mad_logging_library can provide a get_logger_config() that will help the user to configure the logger adequately, but logger.configure() should be called from the if __name__ == "__main__" block inside your sample_app.

Does that look to make sense?

If an user of mad_logging_library is also using Loguru, he will configure the logger according to its preferences. A third library should not interfere with its logging configuration by default. Otherwise, the user ends up with an additional stdout sink which isn't desired. If he decides to enable("mad_logging_library") logs, then it may result with duplicated messages if he added it's own stdout sink.

I am preparing some documentation to explain these principles. I hope it will make things clearer.

[vikramsubramanian]

Yes it definitively helps!

My use case is that users of this library are collegues that are not developers and they "don't care/know" about logs having the same format throughout our systems. That's why I initially wanted to expose an already configured instance of logger from the library.

Advantage of doing so is that I can create high level sinks that exports those logs in some sort of ELK to do full text search and I am sure that all apps they write have the same output.

If that is not the way to go, I'll have to explain them how to do it!

[vikramsubramanian]

If you're use case requires the logger to be configured from within the library, then go ahead. :+1:

It's just a design that might be surprising to the end user for the reasons explained, but technically it's not a problem.

[vikramsubramanian]

Perfect! Super clear now. 👍

[vikramsubramanian]

Great! As it seems solved I'm closing this issue then. ;)