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.

Motivated in large part by #2313

[rhuva]

I was asked to comment on this. I am nor sure I am the right person to comment though. Deferred imports means you import the module only when it's needed rather than at the top of the script? The version of IMPROVER we're running at MSS seems to have mostly imports at the top of the scripts. Granted I do see how it would run faster if the import was deferred rather than just importing everything at the start (assuming there are some less commonly used modules whose imports could be deferred to inside the functions where they're used).