ESM Master Redesign

[pgierz]

In its current state, esm-master relies heavily on a finalised config with parts also filled out needed for experiment running. This is not necessary for the goal of esm-master, and it should not need all that information.

We should collect and document cases where this causes headaches in this issue, and use it as a place for a possible redesign discussion.

Here's some pseudo-code that would make me happy if it were reality:

from esm_tools import get_config

class EsmToolsSoftware:
   def __init__(self, name, *args, **kwargs):
       self.name = name
       raise NotImplementedError("You need to use a subclass for this, we only define the interface here!")
    def comp(self):
       ...
    def get(self):
       ...
       
class EsmToolsComponent(EsmToolsSoftware):
    def init(self, name, *args, **kwargs):
       self._config = get_config(f"components/{name}")
       super().__init__(name, *args, **kwargs)

esm-master CLI then reduces to:

@click.group
def cli():
    ...

@cli.command
@click.argument("name")
def get(name):
    EsmToolsClass = ComponentOrSetup(name)  # Use your imagination
    esm_obj = EsmToolsClass(name)
    esm_obj.get()

[mandresm]

In essence we need an esm_master recipe as we have for esm_runscripts. At the moment it is using the prepare recipe from esm_runscripts, and that's why it tries to do coupling stuff.

[mandresm]

ESM-Master needs to rely on the finalized config because the users might write a lot of interdependent things in their config yamls and they might expect that it works the same way for esm_runscripts and esm_master. And indeed, I know for a fact that users do this all the time.