Hello,
I am using the OpsGenie SDK, which is autogenerated using Swagger, and was most surprised to find printing urlib3 retry notices out to stderr in my application.
The culprit appears to be the default behaviour of configuring a stderr StreamHandler here:
https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/python/configuration.mustache#L133
This is in contradiction to the guidance in the Python logging docs: https://docs.python.org/3/howto/logging.html#configuring-logging-for-a-library
Most notably, these docs say:
If the using application does not use logging, and library code makes logging calls, then (as described in the previous section) events of severity WARNING and greater will be printed to sys.stderr. This is regarded as the best default behaviour.
So if the Swagger template did not set up this StreamHandler, the default behaviour for an application that does not configure logging would be the same.
Instead, what is happening now is that this StreamHandler interferes with applications that do configure the desired logging handlers, and causes duplicate warnings to be logged to stderr, in addition to the ones that are being captured by the other handlers configured by the application.
Also from the Python logging docs linked above:
Note It is strongly advised that you do not add any handlers other than NullHandler to your library’s loggers. This is because the configuration of handlers is the prerogative of the application developer who uses your library. The application developer knows their target audience and what handlers are most appropriate for their application: if you add handlers ‘under the hood’, you might well interfere with their ability to carry out unit tests and deliver logs which suit their requirements
To make this a bit more concrete, in our application we never expect any output to stderr, and as a fallback we capture any and email it. An unintended consequence of adopting a Swagger-generated API is that now the application has started generating stderr under certain circumstances, which is both surprising and undesirable.
Hope that makes sense? Keen to hear thoughts...
cc the python technical committee @taxpon @frol @mbohlool @cbornet @kenjones-cisco
I would be in agreement to remove https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/python/configuration.mustache#L128-L138 as it does violate the expectations of a library.
If the application wants to see logs from the library, then they should configure the type of logging Handler they want for the library. That is the python way.
@asqui @kenjones-cisco I've filed https://github.com/OpenAPITools/openapi-generator/pull/480. Please review when you've time.
Most helpful comment
I would be in agreement to remove https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/python/configuration.mustache#L128-L138 as it does violate the expectations of a library.
If the application wants to see logs from the library, then they should configure the type of logging Handler they want for the library. That is the python way.