Icon namelist non optional

[leclairm]

As advised by @DropD , we remove the necessity of ICON namelists being apparently optional for ICON tasks by using @dataclass(kw_only=True). This is now used all over the code base.

Some doctests are also added to ConfigNamelist and ConfigIconTask

[agoscinski]

I am fine with using the kw_only, it only restrains us from using the constructor with positional arguments which I don't think is important. Can we add a test that tests that it is optional? The test I see still adds a namelist.

EDIT: Wait as far as I experience, the namelist was not optional before. I thought this PR would make it optional, but the title says it is made non optional. If one does not have to modify anything in the namelist, then one does not need to specify the namelist in the config yaml as the names are hardcoded and they are assumed to be in the rootdir.

[leclairm]

EDIT: Wait as far as I experience, the namelist was not optional before. I thought this PR would make it optional, but the title says it is made non optional. If one does not have to modify anything in the namelist, then one does not need to specify the namelist in the config yaml as the names are hardcoded and they are assumed to be in the rootdir.

We actually need the namelists (plural) input from the user. Otherwise we need to make assumptions on where they lives (so rootdir and no subfolder of it for instance) and on the file name, which is is only hard coded for the master namelist but not the other ones (there will always be at least 2 namelists). Before the PR, namelists was non optional in practice but optional in the class definition of ConfigIconTask. So this PR can be considered part of #88.

[agoscinski]

Okay I see that it simplifies handling for now, and before this PR we only had it optional on the parsing and not optional on the workflow side. To make this consistent would be nice. But in principle we could make assumptions about where the namelists are and make it optional in the future?

on where they lives (so rootdir and no subfolder of it for instance)

We already make the assumption that they are relative to the rootdir, can't we make the assumption that they are in rootdir if not specified?

and on the file name, which is is only hard coded for the master namelist but not the other ones (there will always be at least 2 namelists).

But aren't the other namelists specified in the master namelist?

[leclairm]

Frankly, I really don't see the point of making config namelists optional while being actually implicitly required

• Pros:
  • [user] spare one specification in the config file
• Cons:
  • [user] non explicit mention of the namelist files
  • [dev] adding all the code to treat the default case
  • [dev] handle the | None part of the type everywhere or add a canonical class just for that
  • [dev] test the default case specifically