Fortran package manager or python package manager?

Hi all,
I would like to create a repository called numerify which is provide numerical methods implemented in fortran and wrap these fortran files in python functions and user will work with python API.
The question is which one is better for this project?

  1. Using python package manager for building and releasing project
  2. Using brand new fortran package manager
1 Like

I think both. To build and release the Python package you need 1. Then you also need to build the Fortran library. For that you can use the usual ways, or your can use fpm. I recommend fpm.

1 Like

What about f2py for converting fortran codes to importable extension modules instead of building them via fpm?

I don’t have experience with f2py but @melissawm does, and perhaps others. That would be a different approach, orthogonal to fpm.

With fpm we’d need to enable building a shared (.so) library, which you’d then interface from Python via ctypes module.

1 Like

Thank you @milancurcic

I’d strongly suggest avoiding f2py, since it essentially only supports F77 features. If you must use an automated wrapper f90wrap is better. Its best to do neither, and proceed via the library mechanism @milancurcic suggested.

1 Like

Thank you @rgoswami for your suggestion.
I will use OpenMP in my fortran codes, can f90wrap generate multi-threaded extension modules?

f2py actually supports some f90 features, but not all (notably derived types). I’m not very familiar with fpm, but I wonder if some of this couldn’t be done using only conda.

1 Like

I’ve recently played around with f2py (for linking my python and fortran codes), and it seems to support some F90/95 features.

F2PY Users Guide and Reference Manual
https://numpy.org/doc/stable/f2py/

For example, we can pass Numpy ndarray to Fortran assumed-shape arrays, like written in these Question and Answer pages.

However, as far as I experienced, f2py tries to perform many things as automatic as possible, which sometimes makes the internal workings not very clear from the user side (IMHO), which might have pros and cons. Although I think the user can do any “low-level” things with f2py (if desired), it may be more straightforward to use other tools for C-FFI + write necessary wrapper functions by ourselves (rather than relying on auto-generation like f2py). I’ve recently read “High Performance Python” (book), and Chap.7 has a nice summary of some tools like ctypes, cffi, f2py, and cython (with their comparisons, potential pros/cons, etc). For example, cffi seems pretty straightforward to use (but I haven’t played with it yet…)

https://cffi.readthedocs.io/en/latest/index.html
https://cffi.readthedocs.io/en/latest/goals.html

1 Like

Python users have somehow managed to use Fortran code for years, so there are working solution for making such Python libraries that are well supported. SciPy’s use of f2py is a good example.

Another solution is to use Fortran C interop and wrap that code with Cython, which again is well supported.

Of course, calling the methods from Python will incur an overhead as the user-defined routines will be Python callbacks (for f2py this is the case).

2 Likes

The long term solution I think is to have the Fortran code managed by fpm. And the Python code by pip. f2py can be used to generate the Python code.

And we can ensure that fpm works great with Python and f2py.

1 Like