Custom user-defined location for custom project CMOR fixes

[sloosvel]

Is your feature request related to a problem? Please describe.

In a similar fashion to #1623 (solved in #1625 ), when working with custom projects that work with CMOR-like data, it would be useful to be able to implement fixes without the obligation of having to add beforehand the project or the fixes in the repository.

Would anybody oppose to that? @ESMValGroup/esmvaltool-coreteam

[bouweandela]

It would be good to talk about this at the upcoming @ESMValGroup/technical-lead-development-team meeting and it would be good if the @ESMValGroup/userengagementteam and @ESMValGroup/scientific-lead-development-team could also think about this. So far, the design strategy has been to encourage people to contribute to the project by making them implement features in the existing code base if they need them. This makes the threshold for contributing lower because the code is already in the right place once you've written it. The downside is that it makes the learning curve for extending the tool steeper.

Examples of this are the integrated fixes mentioned here, but also preprocessor functions (we could allow any Python function, not just the preprocessor functions integrated in ESMValCore) and the location of built-in recipes and diagnostics (we could make the path to these configurable from config-user.yml).

[bouweandela]

@sloosvel Could you tell us a bit more about this data? Why is it so special that it is not relevant to anyone? Will it not be made publicly available?

[sloosvel]

It's not so much about the data being relevant or not. And it could very well be that certain partners might not be comfortable sharing the data publicly. But that depends on each individual situation.

To me, and I think that to many others, this feature would be useful because fixes are the first step in the development and they have always been a big bottleneck and a struggle to get in the Core. Project deadlines can be tight and it puts a lot of pressure in people developing solutions for projects if they depend of fixes that are left hanging. A certain python function can always be called inside a diagnostic, while a preprocessor for it does not exist. This is not the case for fixes.

Once the project is over, has a working solution, or the data providers don't have privacy concerns, I am sure that everyone would be happy to the contribute them to the repository. But in terms of development, anticipating all the issues that may appear when working with new data and trying to fit that with the release schedule, is something very difficult to handle.

[bouweandela]

A certain python function can always be called inside a diagnostic, while a preprocessor for it does not exist.

If you need the function early on in the preprocessing chain, that would mean moving all preprocessing to the diagnostic, which would be more difficult to maintain and computationally very inefficient.

Once the project is over, has a working solution, or the data providers don't have privacy concerns, I am sure that everyone would be happy to the contribute them to the repository.

My experience is that once projects are over people are very unlikely to contribute because they have no budget left to do it from.

Note that I'm not against the feature, I think it could be great, but I do think we should decide as a team if this is a direction we want to take.