-
Notifications
You must be signed in to change notification settings - Fork 275
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
logging level consistency #1108
Comments
I am in favour of reworking Found another old issue related to this #750 p.s. When I use the word rework I don't mean we should wait for the great TUF rework, I think this can be done on the current codebase. |
tuf.log might have a use case, but to me it looks like application functionality put into a library... As an example if an application for some reason wanted to log only tuf logs into a file it could just do
so EDIT: This is not an area of expertise for me: I might not understand how Python logging is supposed to work |
I was referring to this doc: https://docs.python.org/3/howto/logging.html#configuring-logging-for-a-library. Saying this also as a non-expert on Python logging ... |
The actual log level fixes should be fairly quick fixes: there's only 8 instances of |
There are still some logging annoyances that make it hard to A) see actual errors in e.g. unittest logging but also B) difficult to decide what to do WRT tuf logging in an application:
There have been some improvements in this #1083, #1039, #1093, #983 but the core issue is still there: In my opinion ERROR and CRITICAL should only be used when tuf is in an error state, not when it has correctly identified a security issue.
For testing this I suggest modifying e.g. test_update.py:
and running
python3 test_updater.py TestUpdater
(this will only print ERROR and higher levels)The text was updated successfully, but these errors were encountered: