Updated doc about fixes and added type hints to fix functions

[schlunma]

Description

This PR updates the outdated doc about fixes (add the necessary function get_cube_from_list to fix_metadata and replaced the old extract_strict with extract_cube) and adds type hints to many fix-related functions.

There is NO change in functionality.

Links to documentation:

• https://esmvaltool--2160.org.readthedocs.build/projects/ESMValCore/en/2160/develop/fixing_data.html#create-the-fix
• https://esmvaltool--2160.org.readthedocs.build/projects/ESMValCore/en/2160/recipe/preprocessor.html#dataset-specific-fixes

---

Before you get started

• ☝ Create an issue to discuss what you are going to do

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.

• 🧪 The new functionality is relevant and scientifically sound
• 🛠 This pull request has a descriptive title and labels
• 🛠 Code is written according to the code quality guidelines
• 🧪 and 🛠 Documentation is available
• 🛠 Unit tests have been added
• 🛠 Changes are backward compatible
• 🛠 Any changed dependencies have been added or removed correctly
• 🛠 The list of authors is up to date
• 🛠 All checks below this pull request were successful

---

To help with the number pull requests:

• 🙏 We kindly ask you to review two other open pull requests in this repository

[codecov]

Codecov Report

Merging #2160 (81d43ce) into main (facd794) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #2160   +/-   ##
=======================================
  Coverage   93.10%   93.10%           
=======================================
  Files         237      237           
  Lines       12816    12822    +6     
=======================================
+ Hits        11932    11938    +6     
  Misses        884      884           

Files Changed	Coverage Δ
esmvalcore/cmor/fix.py	100.00% <ø> (ø)
esmvalcore/cmor/_fixes/fix.py	98.59% <100.00%> (+0.02%)	⬆️
esmvalcore/preprocessor/_io.py	87.10% <100.00%> (+0.25%)	⬆️

[valeriupredoi]

thanks, Manu! A couple minor points from me 🍺

[valeriupredoi]

I would put a check on file's type in here (str is a bit too general, so we are exposing us to fails if load is called with load("s3://cow")) - a placeholder so we maybe get support for eg object storage "files" in the future

[valeriupredoi]

sorry - I was a bit too vague on this: I'd defo investigate what type of str is supported inside the load func (or maybe create an IO or Load error class); also maybe nice to add a test case

[schlunma]

Sorry, I don't fully get your comment - at the moment, only valid Path and str objects can be passed to load. Since a couple of version iris can digest Path objects, that's why I am calling Path(file) at the beginning of the function now. Here, we needs str(file) for the attribute to be properly set.

Since now other types are supported, I don't think we need to add additional checks here. If the path is invalid, we will either get an iris error during iris.load_raw or a ValueError from our code.

[valeriupredoi]

indeed, and my second phrasing of the comment was as vague as a Tory declaring their taxes - what I really meant was we should probably think of examining the str path a bit more in the context when it is not a valid string of a POSIX path, and throw up the error, but a little bit more tailored towards cases such eg the str path starts with "s3" or "https" - the first steps towards supporting remote/object store files. Clearly, not a priority now, so totally up to you if you want to go start going down this rabbit hole 🐰

[valeriupredoi]

thanks a lot for addressing the review comments @schlunma - if you don't (and I expect you not to) want do anything about #2160 (comment) then this is good to be merged, you wanna poke the TLT for a merge? 🍺

[schlunma]

Thanks for reviewing V! You're right, I don't want to address this here 😅

[schlunma]

In order to proceed with #2157, it would be nice to have this merged today (there will be a lot of merge conflicts which I would like to solve before finalizing #2157). Since this is a pure maitenance PR, I don't think this be a problem. Any objections @ESMValGroup/technical-lead-development-team?