Skip to content
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

[Python] Swagger API Clients will log to stderr by default #236

Closed
asqui opened this issue Jun 6, 2018 · 3 comments
Closed

[Python] Swagger API Clients will log to stderr by default #236

asqui opened this issue Jun 6, 2018 · 3 comments

Comments

@asqui
Copy link

asqui commented Jun 6, 2018

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...

@wing328
Copy link
Member

wing328 commented Jun 8, 2018

cc the python technical committee @taxpon @frol @mbohlool @cbornet @kenjones-cisco

@kenjones-cisco
Copy link
Contributor

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.

@wing328 wing328 modified the milestones: 3.0.1, 3.0.2 Jun 11, 2018
@jmini jmini modified the milestones: 3.0.2, 3.0.3 Jun 18, 2018
@ackintosh ackintosh modified the milestones: 3.0.3, 3.1.0 Jun 27, 2018
@wing328 wing328 modified the milestones: 3.1.0, 3.1.1 Jul 6, 2018
@wing328
Copy link
Member

wing328 commented Jul 6, 2018

@asqui @kenjones-cisco I've filed #480. Please review when you've time.

@jmini jmini modified the milestones: 3.1.1, 3.1.2 Jul 18, 2018
@wing328 wing328 modified the milestones: 3.1.2, 3.2.0 Jul 25, 2018
@wing328 wing328 closed this as completed Jul 26, 2018
@wing328 wing328 modified the milestones: 3.2.0, 3.1.1 Jul 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants