-
Notifications
You must be signed in to change notification settings - Fork 281
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
Adopt logging -- or something? #3413
Comments
Enabled by #3785 and the inclusion of iris.config.get_logger |
This came up in a dev discussion this morning. Having started to use logging around Iris, we would like to collectively agree on exactly how we will use it. Relevant concerns
|
My two cents
|
Bumped into this while working on #4099 From the logging module description of levels, I think we should be using 'warning' when we discover and/or workaround something that "should not happen". The bottom line for me is that we should not be totally silent, when working around things which are actually "wrong" : And especially in the case just investigated, when an input file is formatted incorrectly, and we are making the best of it. But I do agree with @trexfeathers that we could maybe engineer a default behaviour that emits a one-time message "that warning-level events have occurred". Other thoughts:
|
Additional note : unfinished business / tech-debtFrom my experience on #4099 I am now suspicious of most of the existing usage of 'logger' in the ugrid code. So, I think a lot of the existing calls don't have this + may be bugged.
Unfortunately I'm not just fixing these now, as I think to do that we should really add tests for these code sections |
EDIT: my mistake for taking inspiration from metadata.py rather than the other two examples. I will try to fix this in due course. Sorry.
@pp-mo I'm struggling to see how this could be the case.
|
I think my point only applies to the ones in Whereas, in |
After some effort, I worked this out. The testing code is replacing the real logger with the one used to record logging in the test, E.G. looking at this test. So, in that test, I added another
Now I do get the expected error when I run the test.
|
Afterthought ... In that case, that should make it pretty easy to fix this after all, and ensure that the tests are fully exercising the code. |
I think we should draw this discussion to a close here on this issue. Remember that we do now have GitHub Discussions which might be more appropriate. Nevertheless, I'll draft an IEP to cover this. Which will promote a more concise and transparent summary of what's been proposed and how this should be applied with iris 👍 Ping @knight |
Somewhat related, re improving tests of logging usage : #4106 |
Uncertainty at this point makes this issue inappropriate for a release - needs internal discussion |
From @jamesp:
In conversation, we agreed that any time that Iris' behaviour deserves communication to the user should either be a |
If we better categorise Iris' warnings, we can then educate the user base on catching the categories they are comfortable ignoring. We could also provide one or more conveniences for opting out of some/all Iris warnings. It seems like the main part of solving Iris' verbosity is user education. This would also be needed with any logging-based solution. |
There is of course a separate argument for implementing logging to aid Iris development. But that was not the original scope of this issue:
|
In a peloton meeting, @bsherratt clarified a couple of technical points :
|
https://github.com/Delgan/loguru is a thing. Perhaps relevant, perhaps not. |
Closing due to recent progress:
|
Silence the noise of
iris
warnings throughlogging
and provide clear guidance to developers on the use oflogging
and associatedlogging
levels, and when it is actually appropriate to usewarnings
in the Iris developers guide.Reference:
The text was updated successfully, but these errors were encountered: