-
-
Notifications
You must be signed in to change notification settings - Fork 382
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
Prevent smart_open from writing to logs on import #476
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not the fix I expected :)
I thought the issue were the global (import-time) logging calls. Not the relative order of imports.
If this works it definitely deserves a code comment!
I did some tests to wrap my head around what's happening. Recording my thoughts here: Before this PR:
After this PR:
I was surprised by "Before 6)": I thought "Before 4)" would be ignored because "Before 3)" already configured the logging system, but that's not the case. "Before 4)" still takes effect. So #475 is less severe than I thought. The application's logging was not messed up – users just saw some cryptic messages in their stderr on smart_open import – incl. indirect import via other libraries. |
Btw with this PR, users will not see these The global (import-time) logging is weird. Perhaps this should be a |
@radim @menshikh-iv OK, I tried a different approach. Instead of logging the import error, we handle it silently, and instead raise an exception when the user tries to use the module that raised the import error. For example, here's what they'll see if they try to open a GCS URL without the google-cloud-core library installed:
Please have a look and let me know what you think. If this is acceptable, then we can roll back the previous logging-related commits. |
Wrong Radim 😉 |
I meant @piskvorky, whoops |
smart_open/__init__.py
Outdated
__version__ = version.__version__ | ||
|
||
logger = logging.getLogger(__name__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this revert? Isn't it safer to add the handler early on, to avoid issues like this in the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reverted it because it was no longer a necessary part of the solution.
If you think it's worth keeping for future-proofing the existing solution, then I can add it back in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not critical, but it makes sense to add the handler as soon as possible. Who knows what the contributed modules will do in the future (a missed logging call on import…).
Motivation
Checklist
Before you create the PR, please make sure you have: