-
Notifications
You must be signed in to change notification settings - Fork 44
Add esmvalcore.config module
#1769
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
Conversation
b33dc26 to
ad1ad77
Compare
Codecov Report
@@ Coverage Diff @@
## main #1769 +/- ##
==========================================
+ Coverage 91.16% 91.48% +0.31%
==========================================
Files 202 201 -1
Lines 10882 10878 -4
==========================================
+ Hits 9921 9952 +31
+ Misses 961 926 -35
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
160d2fe to
3b25fe0
Compare
7093fcd to
aaf9a4a
Compare
69e6918 to
0b15dc6
Compare
| @@ -0,0 +1,130 @@ | |||
| """Functions dealing with config-user.yml / config-developer.yml.""" | |||
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.
Note to reviewer: this file was moved here from esmvalcore/_config/_config.py, but because all the old code for reading config-user.yml was removed from it, git doesn't recognize it.
d82146e to
004a687
Compare
|
@ESMValGroup/esmvaltool-coreteam It would be great if some of you could have a look at this. |
|
I try to find some time this week to have a look at this 👍 One question at the very beginning: as far as I understand this is only a refactoring and does not change any functionality, is that correct? So we would not expect any recipe output to change, right? |
|
Thanks! Indeed I wouldn't expect any recipe output to change. Maybe some command line option does no longer work, but even that seems unlikely because we have fairly good test coverage and we've already been using the |
schlunma
left a comment
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.
Thanks Bouwe, great work! This really simplifies the configuration module and making it public is also a good idea.
I tested this with a bunch of recipes, different command line options, and different options in the config file. Everything worked fine!! 🎉
I have a couple of comments on the code itself, and two more general comments:
- Running recipes with this produces a bunch of
ESMValCoreDeprecationWarning: The private module esmvalcore._config has been deprecated in ESMValCore version 2.8 and is scheduled for removal in version 2.9.0. Please use the public module esmvalcore.config instead.warnings. I guess they come from ESMValTool, not ESMValCore; is this correct? - Why did you decide to keep the
esmvalcore.experimental.configmodule? It's just a copy ofesmvalcore.config. IMHO we could also deprecate this.
|
Thanks for the very thorough review @schlunma! I didn't manage to work my way through all comments, will continue tomorrow.. |
There were also some coming from ESMValCore, but I suppressed those now. Once #1609 completely merged, the suppressions should no longer be needed, but I didn't want to change esmvalcore/_recipe.py in this pull request.
Good idea, I just did that. |
|
Thanks a lot for reviewing @schlunma! I think I have addressed everything now, could you have another look please? |
schlunma
left a comment
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.
Awesome, thanks for implementing my comments @bouweandela! I re-tested this and everything works as expected 🚀
@ESMValGroup/esmvaltool-coreteam would be great if someone could merge this, thanks 👍
|
I shallz! But am not entirely happy with the cov test failing, lemme have a looksee first (before moaning about it) |
valeriupredoi
left a comment
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.
lots of good stuff here, awesome work, guys! Just a couple quick and dirty pointers from me, I will merge since the cov test is complaining about old code 👍
| if session['compress_netcdf']: | ||
| logger.warning( | ||
| "You have enabled NetCDF compression. Accessing .nc files can be " | ||
| "much slower than expected if your access pattern does not match " |
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.
this is cryptic - what does "if your access pattern does not match" mean?
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.
reminds me of "Negative, Ghost Rider, the pattern is full!" 😆 (Top Gun)
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.
You can read more about HDF5 compression here: https://support.hdfgroup.org/HDF5/doc/Advanced/Chunking/ (and see also here https://docs.xarray.dev/en/stable/user-guide/io.html#chunk-based-compression). What it comes down to is that enabling compression will create compressed chunks of data inside the file. In order to read a single point from a chunk, you need to decompress the entire chunk. So if you first save with chunks that are e.g. one entire lat/lon slice and then try to read a long timeseries from a single lat/lon point this will be very inefficient.
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 know all that stuff, man, cheers, but a user will not (in 98% of cases) 😁
| """ | ||
| from ._config import DIAGNOSTICS, configure_logging | ||
| from .config._diagnostics import DIAGNOSTICS | ||
| from .config._logging import configure_logging |
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 am sure there is a good reason why these imports are not happening at top level, but why are they not happening at top level?
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.
Because it gives a very slow user experience, e.g. if you run esmvaltool --help, you expect a prompt response. However, if it needs to import everything and load all the cmor tables, this takes up to a few seconds and gives the command line a very sluggish feel.
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.
ah gotcha, very cool point I didn't think of 🎖️
| print(f"ERROR: output directory {session.session_dir} already" | ||
| " exists, aborting to prevent data loss") |
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 am with Manu on this one, but OK since mkdir will raise something anyway
Maybe it shouldn't even do that, right? Maybe it should just automatically come up with an another directory name? I tried to implement something like that here: 52af816. |
|
Thanks for reviewing @schlunma and merging @valeriupredoi! 🥳 |
indeed, but that's a magnet for disaster, we have to be careful with our data spawning on HPC's |
|
Apparently this broke our CI tests (I already re-started them again once). Anyone got an idea what's going on there? |
|
@zklaus 🦅 =eyed it and raised it on Slack - tis the implicit line appearing twice in setup.cfg |
Description
Make
esmvalcore._configpublic by moving it toesmvalcore.configand remove duplicate configuration code by moving it from theesmvalcore.experimentalmodule toesmvalcore.config.This also adds proper caching of the CMOR tables based on the modification time of
config-developer.yml, leading to a considerable speedup of the tests.Closes #1568
Closes #1579
Related to (the by now somewhat outdated) #498
Related to ESMValGroup/ESMValTool#2736
Part of #1609.
Deprecations:
esmvalcore.cmor.table.read_cmor_tables(cfg_developer):cfg_developerused to be the content of the config-developer file already loaded usingyaml.safe_load, from now on it should be just the path to the file. The old behavior will be supported until version v2.10.esmvalcore._config: this is a private module that is not part of the public API. However, because it is used in ESMValTool, it will remain available until v2.9. Theesmvalcore.config.CFG.start_sessionmethod should be used as a replacement for theread_config_user_filefunction.esmvalcore.experimental.config.Session.to_config_userandfrom_config_userare deprecated and will be removed in v2.9.Link to documentation: https://esmvaltool--1769.org.readthedocs.build/projects/ESMValCore/en/1769/api/esmvalcore.config.html
Before you get started
Checklist
It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.
To help with the number pull requests: