`pyMoist` setup

[FlorianDeconinck]

This sets up the NDSL port of the Moist physics, with an emphasis with our intern work starting soon.

We mimic the code structure of FVdycoreCube_GridComp, without the external repository this time:

| ...
|── python
│   ├── interface # <-- Interface code to bind Fortran and Python
│   │   └── ... 
│   └── model # <-- NDSL numerical code as pa
│       ├── pyMoist # <-- Numerical code done with NDSL
│       │   └── ... 
│       ├── README.md
│       ├── setup.cfg
│       ├── setup.py
│       └── tests # <-- Regression testing vs Fortran
│           └── ... 
├── ...

The idea is to keep development both as a GEOS inline (via the interface) and as a self-standing python package (for quick porting).

The code has a stub for RadiationCoupling code & test. Code guidelines is minimal via pre-commit.

[pchakraborty]

Does the model directory serve a purpose? Can't we have pyMoist pulled one level up?

[FlorianDeconinck]

Does the model directory serve a purpose? Can't we have pyMoist pulled one level up?

I was trying to replicate the dycore structure, but arguably this is not a necessity. I don't like generic folder, so maybe you are right and we should be more clean. What about something like this:

| ...
|── pyMoist 
│       ├── interface # <-- Interface code to bind Fortran and Python
│            └── ... 
│       ├── pyMoist # <-- Numerical code done with NDSL
│       │   └── ... 
│       ├── README.md
│       ├── setup.cfg
│       ├── setup.py
│       └── tests # <-- Regression testing vs Fortran
│           └── ... 
├── ...

[pchakraborty]

I like this :-)

Now I'm nitpicking, but pyproject.toml seems to be the preferred configuration file these days (https://packaging.python.org/en/latest/flow/#the-configuration-file). It can use setuptools as the build backend.

[FlorianDeconinck]

I like this :-)

Now I'm nitpicking, but pyproject.toml seems to be the preferred configuration file these days (https://packaging.python.org/en/latest/flow/#the-configuration-file). It can use setuptools as the build backend.

Okay let's got for that I'll like better too.

Yeah people are moving to pyproject.toml and I actually did that myself too. Now, it's not as clear cut as it looks when diving in. The gatekeeper of the pyproject systems are pretty strict on a lot of more advanced usage that the script form of setuptools allows (including building compiled language for example), which lately has me kind of slow down transition. That said the pyproject is a plug and play, so it's definitely a better solution for forward proofing, I just not sure of how much flexibility you end up using (I already had issues with pulling tagged local git as a dependencies, for example).

Another thing is that the other package in the ecosystem are all setuptools based. Likewise, I'd rather use ruff than flak8/pylance but all other packages are flak8 so I follow.

Overall I think I'll keep setuptools for now. I have a rather distant ticket for challenging/upgrading the infrastructure of the python packages as a whole, including pre-commit, lint, install, etc. which should be done semi-often.

[pchakraborty]

Overall I think I'll keep setuptools for now. I have a rather distant ticket for challenging/upgrading the infrastructure of the python packages as a whole, including pre-commit, lint, install, etc. which should be done semi-often.

Sounds good.