feat!: Add option to omit logging.StreamHandler during setup

[ZeJ0hn]

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #38 🦕

[daniel-sanche]

Thanks for the contribution. This is something I've been looking at, but I'm still in the information gathering phase. My impression so far is that the extra handler is needed for some environments (AppEngine?), but causes duplicate entries in others (GKE). I think I'd rather fix the library's logic to add the handler only when appropriate, rather than make it user-optional. But I'm trying to improve the test coverage first to make sure that I can do that without breaking any environments

What do you think? I'm interested in hearing your experiences as a user of the library

[ZeJ0hn]

Hi, my experience is very simple : "Why do I have my logs duplicated ???"
It's very confusing to have this StreamHandler by default, especially because there is no mention about it in the documentation, and once you discover it, there is no way to disable it (except by filtering manually all handlers).
What I expect from a library is to do exactly what it is made for: in this case, send logs into Stackdriver.

A StreamHandler can be useful in some case (debug in local, etc) but I would prefer to add it myself, because I know that I need it.

From my point of view, for this case, the best should be to simply remove the StreamHandler and let the user add one if he needs it.
An intermediate solution is with the arguments stream_handler=False because the user is able to have the control on it.

I don't like the solution to disable or not the StreamHandler function of the environment because I think the library should have the same behavior everywhere.

Here's my point :-)

[daniel-sanche]

From my point of view, for this case, the best should be to simply remove the StreamHandler and let the user add one if he needs it.

I agree, so my plan is to remove the extra StreamHandler entirely, rather than keeping it as an optional argument. I'm going to close this PR for now, but I'll prioritize this fix. We're on release freeze now due to the long weekend, but you can expect to see the fix in the next couple weeks

[ZeJ0hn]

@daniel-sanche I can remove the handler and push a PR if you want.
I'm happy to help :-)

[daniel-sanche]

Thanks for the offer, but I just opened this one-liner here: #106. I ran through some manual tests, and couldn't see any issues with just removing the extra handler

If you run into any more bugs while using the library, future bug reports and PRs are appreciated though!
Thanks