powellb
Factor the OA Fortran lib out of the package
Building Fortran extensions in Python became quite a nightmare with Python dropping distutils, numpy dropping numpy.distutils, setuptools >=65 dropping the vendored distutils, etc. Also There is no clear substitute (meson? cmake?). Factoring out the OA part will allow the rest of the package be noarch, easy to build and maintain, while depending on an optional OA Fortran extension that, can evolve faster outside of this package, maybe even get a re-write in another language.
If that is something of interest please let me know and I can help with the re-factor.
There are other Fortran functions in addition to OA that are used throughout seapy. In addition, OA is scattered throughout a number of routines. So, elimination of the fortran code is not a trivial task. We try to use a number of ROMS fortran routines directly to ensure correct calculations (previous Python attempts didn't match perfectly).
Moving away from distutils has been on the priority, but since we haven't upgraded our cluster beyond Python 3.11 it hasn't hit the top yet. Over the next couple of months I had planned to examine the replacement for distutils. It seems it isn't too onerous.
In addition, OA is scattered throughout a number of routines.
This factored out package would still be a dependency here and that would not change. The idea would be to make a build migration easier by having it in its own package.
@ocefpaf , @powellb - I had a crack at building the fortran extensions using meson-python and it seems to work. I followed the guidance from https://github.com/larsbuntemeyer/pyfort and followed examples from Scipy for propagating the subdirectories correctly. To make it work, I had to include a meson.build file in each directory with the python source files (along with cdl, npz, etc...). I've created a dummy seapy/external/__init__.py to keep as backwards compatible as possible.
I ran some quick tests with a ROMS test case I have that uses seapy to interpolate Copernicus data with OA and it worked like the conda version. It surely needs more testing, but seems promising. If there interest, I can make a PR.
If you want to test it, I wrote a quick installation howto with pip here: https://github.com/rsoutelino/seapy?tab=readme-ov-file#install-with-pip
I don't know if there is a test suit here, it would be nice to add some basic import tests, and, if time permits, actual coe tests for the compiled extensions. I still believe that a 2-package approach would benefit to decouple the Fortran modules from the pure Python code here. The smallest compiled unit we can get, the easier it is to build, update, debug, etc.
@ocefpaf . Yup, agree a 2-package approach would still be beneficial. I added some tests, tox and GHA in my last push to main for good measure anyways.
https://github.com/rsoutelino/seapy
This is great. Thank you both for these ideas, and the work you've done Rafael.
I will find some time over the next few days to review your repository and test it with some of my own data.
Sorry for the delay in this. It has been a hectic couple of months with quite a bit of travel.
@rsoutelino I encourage you to submit a PR for the meson build. I had started to convert to a meson build, but had a couple of errors I didn't get through to correct.
To address @ocefpaf comments, I have been reading about possible conditional installations, but the move away from setup.py seems to prevent it. I actually have a version that works with old numpy.distutils versions that tries to compile the extensions and if it fails, it just continues fine.
I do have a version that simply displays a warning that a function is not available if a user tries to call it without having installed the extensions.
At this point once the PR is added to move to setuptools and meson, unless we can find a way of doing conditional install, I will simply continue as-is. To use seapy requires scipy and numpy which both require a fortran compiler, so it is a low-bar.
Sounds good, @powellb. I've created the PR: https://github.com/powellb/seapy/pull/73.
With the latest batch of updates, it build fine and doesn't require gfortran, but it does require a c compiler after f2c does the conversion. If there is a failure in the build, but the package is installed, seapy will work unhindered unless you call a routine that relies on the compiled code, and it will simply print an error message.
I will close the issue.