Add loading and running recipes to the notebook API

[stefsmeets]

Hi everyone, this PR implements an api to load and run recipes in an interactive jupyter notebook.

This PR is mostly complete in terms of what it is supposed to do. The thing that is missing is to have good test. I'm thinking we should have some very basic test recipes that we can run to test the API.

Also implements bugfix that closes #953

To do

• Look at issue with multi-processing (max_parallel_tasks != 1) -> Seems to work as intended.
• Implement unit tests with basic recipe for testing (.yml or maybe pass dict directly?)
• Add function to generate rootpath entry for user config ESMValTool_sample_data#15 merged
• Bump version to 0.0.3 ESMValTool_sample_data#16 merged and release/depend on v0.0.3

Tasks

• Create an issue to discuss what you are going to do, if you haven't done so already (and add the link at the bottom)
• This pull request has a descriptive title that can be used in a changelog
• Add unit tests
• Public functions should have a numpy-style docstring so they appear properly in the API documentation. For all other functions a one line docstring is sufficient.
• Circle/CI tests pass. Status can be seen below your pull request. If the tests are failing, click the link to find out why.
• Codacy code quality checks pass. Status can be seen below your pull request. If there is an error, click the link to find out why. If you suspect Codacy may be wrong, please ask by commenting.

If you need help with any of the tasks above, please do not hesitate to ask by commenting in the issue or pull request.

---

Follows up on #901 and #868
For more discussion, see issue #498
Documentation: https://esmvaltool--907.org.readthedocs.build/projects/ESMValCore/en/907/api/esmvalcore.api.html
Demo notebook: https://gist.github.com/stefsmeets/1163eeea765906550f772c15b69e866e

[stefsmeets]

Hi @nielsdrost and @Peter9192 , this PR is ready for review. Could you have a look?

There is still a small issue with the tests on CircleCI that I will have a look at, but I think other than that the PR can be reviewed. The tests are running fine locally.

[stefsmeets]

This test fail seems to be completely random on CircleCI (sometime it passes, sometimes it fails), unrelated to any changed made in this PR, and I cannot reproduce it on my own machine.

self = <tests.unit.preprocessor._regrid.test_regrid.Test testMethod=test_regrid__cell_specification>

    def test_regrid__cell_specification(self):
        specs = ['1x1', '2x2', '3x3', '4x4', '5x5']
        scheme = 'linear'
        for spec in specs:
            result = regrid(self.src_cube, spec, scheme)
            self.assertEqual(result, self.regridded_cube)
>           self._check(spec, scheme, spec=True)

tests/unit/preprocessor/_regrid/test_regrid.py:107: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
tests/unit/preprocessor/_regrid/test_regrid.py:23: in _check
    self.assertEqual(_CACHE[spec], self.tgt_grid)
E   AssertionError: <iris 'Cube' of unknown / (unknown) (latitude: 180; longitude: 360)> != <Mock spec='Cube' id='140365561280592'>

[bouweandela]

Code looks good, though I did not try using it.

Could you have a look at the question about representing CheckLevels in a YAML file? I think this should not be needed, because CheckLevels should not leak to the diagnostic script through the YAML interface, this is supposed to be used by the CMOR checker and nothing else.

Would it be possible to solve the import outside toplevel Codacy issue?

[stefsmeets]

Would it be possible to solve the import outside toplevel Codacy issue?

Yeah, it can be solved, but I think it is clearer where it is now.

[bouweandela]

Yeah, it can be solved, but I think it is clearer where it is now.

If would be great if you could follow the style guide if there is no technical reason for deviating from it. If everyone starts making up their own style the code will become harder to read for everyone.

[stefsmeets]

Yeah, it can be solved, but I think it is clearer where it is now.

If would be great if you could follow the style guide if there is no technical reason for deviating from it. If everyone starts making up their own style the code will become harder to read for everyone.

I don't consider this error be a 'hard' fail from Codacy, sometimes the code reads much better if the import is not at the top of the file. Besides that, Codacy and yapf sometimes conflict as well, so it is unclear what style to use.

[stefsmeets]

@bouweandela This PR is ready to be merged. I worked around the test failure by clearing the cache before the regrid tests, but a better implementation is needed. For more info see #953.

[stefsmeets]

Shoot, now I merged the wrong branch here...

Merge branch 'api_run_output' into api_run_recipe2 🤐

EDIT: all good!

[nielsdrost]

Did a scan of the code (especially changes outside of experimental). Looks good to me.

Changes implemented as requested.