Do we really need enfore deferred imports within metoppv/improver codebase?

[cpelley]

Requiring deferred imports within improver itself introduces a number of configuration issues. In particular, Iris configuration relies on global FUTURE settings, which means we either have to wrap every Iris import within improver, or abandon the idea of deferring the Iris import in improver altogether.

My argument is that imports are already inherently deferred. When using DAGrunner, the execution of a node—and therefore the import of the application module path—only occurs at the point that node is executed.

For paraflow-based execution, I’m less certain that application modules are deferred (and I may be mistaken), but I’m not convinced this distinction really matters. Without deferring imports, they are performed once, and any parallel processes forked from that initial import will already include the pre-imported Iris library. I don’t see the main controlling process having NumPy and Iris imported as inherently problematic—particularly given that we now have a single controlling process, rather than the old makefile-based approach with thousands of controlling processes.