(Spurred by the discussion at eCLM namelist generator separate from WFE)
@jjokella's idea is to move the namelist_generator into its own repository so that it could be developed independently of eCLM. I support this.
Creating the repo is the easy part; the difficulty is in making sure that the project structure is right at the outset. Note that the namespace of a Python library is influenced by its underlying file/folder structure, and this has consequences on how the its public API can be exposed. Thus, if we don't want the eCLM namelist generator to be a frustrating-to-use Python library with unstable library interfaces, its project structure and namespaces have to be right at the beginning.
Moving forward, the namelist_generator can be kept as it is till I find time to setup its own proper separate repo. Presently its scope is limited to the generation of Wuestebach and NRW namelists, which were the only 2 cases tested with this tool.
(Spurred by the discussion at eCLM namelist generator separate from WFE)
@jjokella's idea is to move the
namelist_generatorinto its own repository so that it could be developed independently of eCLM. I support this.Creating the repo is the easy part; the difficulty is in making sure that the project structure is right at the outset. Note that the namespace of a Python library is influenced by its underlying file/folder structure, and this has consequences on how the its public API can be exposed. Thus, if we don't want the eCLM namelist generator to be a frustrating-to-use Python library with unstable library interfaces, its project structure and namespaces have to be right at the beginning.
Moving forward, the
namelist_generatorcan be kept as it is till I find time to setup its own proper separate repo. Presently its scope is limited to the generation of Wuestebach and NRW namelists, which were the only 2 cases tested with this tool.