Separate science components from framework

[ThibHlln]

I suggest to split the framework functionalities and the science it holds by removing the science components from this repository, and by creating distinct repositories for each (set of) science component(s).

The main motivations are:

• have a clean separation of concerns between technical aspects and science aspects
• keep the installation of the framework lightweight (i.e. no need for a user to install all compatible science components if they are not going to use them all, the user can cherry-pick the science components they want to use)
• simplify the installation of the framework for users not interested in Fortran/C-based science components (since these require compilation, they represent a potential source for complications)
• give science component contributors their own space (i.e. repository) where they can have e.g. development branches, and where they can handle releases of new versions themselves without the need to wait for a newer version of the framework to be released – compatibility between framework and science components will be preserved through the specification of the version(s) of cm4twc these science components can run with in their dependencies, e.g. in their requirements.txt

Note, the framework would keep its "dummy" components for testing purposes.

This may complicate slighly the installation instructions and the import statements, but I think it is really a minor inconvenience in comparison with the benefits listed above. However, see below comparisons between having everything in one repository and having separate repositories.

installation

one repository (current)

pip install cm4twc

separate repositories (proposed)

pip install cm4twc cm4twccontrib-artemis cm4twccontrib-rfm

usage

one repository (current)

import cm4twc

sl = cm4twc.components.surfacelayer.Artemis(...)
ss = cm4twc.components.subsurface.Artemis(...)
ow = cm4twc.components.openwater.RFM(...)

md = cm4twc.Model(sl, ss, ow, ...)

separate repositories (proposed)

import cm4twc
import cm4twccontrib.artemis
import cm4twccontrib.rfm

sl = cm4twccontrib.artemis.SurfaceLayerComponent(...)
ss = cm4twccontrib.artemis.SubSurfaceComponent(...)
ow = cm4twccontrib.rfm.OpenWaterComponent(...)

md = cm4twc.Model(sl, ss, ow, ...)

The science components would require to follow some packaging and naming conventions (as shown in the example above), namely:

• follow suggestions in PEP 423: "use the ${MAINPROJECT}contrib.${PROJECT} pattern to store community contributions", where MAINPROJECT would be cm4twc and where PROJECT should be the name of the model from which the science component(s) is (are) originating from
• follow PEP 8's package naming convention "Python packages should also have short, all-lowercase names, although the use of underscores is discouraged", so e.g. acronyms should be lowercased.

Note, while PEP 423 has a "deferred" status, it is based on what sphinx is already doing for community contributions, and appears to be good practice.

In our case, Artemis and RFM projects (e.g. on PyPI) would be named cm4twccontrib-artemis and cm4twccontrib-rfm, respectively. And they would be imported as cm4twccontrib.artemis and cm4twccontrib.rfm, respectively. Repositories for these models have already been created https://github.com/cm4twc-org/cm4twccontrib-artemis, https://github.com/cm4twc-org/cm4twccontrib-rfm.

[ThibHlln]

I've also created a repo containing a template to package components into a Python package compliant with the framework https://github.com/cm4twc-org/cm4twccontrib-template.

Note, I've not committed anything to main yet, so have a look at the dev branch. I intend for this repo to get a new commit to main/a new release for every version of cm4twc released, to reflect any API changes, if any. The first released template will be for cm4twc==0.1.0.