f2py problem with Multi-Python (and Ninja)

[Ole Streicher]

Hi,

I have a package (pybdsf) that currently fails to compile when both
Python 3.12 and 3.13 are installed (current situation). From the log:

------------------------8<---------------------
I: pybuild plugin_pyproject:129: Building wheel for python3.13 with "build" module
I: pybuild base:311: python3.13 -m build --skip-dependency-check --no-isolation --wheel --outdir /build/pybdsf-1.11.1/.pybuild/cpython3_3.13
------------------------8<---------------------

which seems reasonable, and results in the Ninja command:

------------------------8<---------------------
/usr/bin/cmake /build/pybdsf-1.11.1 -G Ninja --no-warn-unused-cli \
-DCMAKE_INSTALL_PREFIX:PATH=/build/pybdsf-1.11.1/_skbuild/linux-x86_64-3.13/cmake-install \
-DPYTHON_VERSION_STRING:STRING=3.13.0 -DSKBUILD:INTERNAL=TRUE \
-DCMAKE_MODULE_PATH:PATH=/usr/lib/python3/dist-packages/skbuild/resources/cmake \
-DPYTHON_EXECUTABLE:PATH=/usr/bin/python3.13 \
-DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.13 \
-DPYTHON_LIBRARY:PATH=/usr/lib/x86_64-linux-gnu/libpython3.13.so \
-DPython_EXECUTABLE:PATH=/usr/bin/python3.13 \
-DPython_ROOT_DIR:PATH=/usr -DPython_FIND_REGISTRY:STRING=NEVER \
-DPython_INCLUDE_DIR:PATH=/usr/include/python3.13 \
-DPython_NumPy_INCLUDE_DIRS:PATH=/usr/lib/python3/dist-packages/numpy/core/include \
-DPython3_EXECUTABLE:PATH=/usr/bin/python3.13 \
-DPython3_ROOT_DIR:PATH=/usr -DPython3_FIND_REGISTRY:STRING=NEVER \
-DPython3_INCLUDE_DIR:PATH=/usr/include/python3.13 \
-DPython3_NumPy_INCLUDE_DIRS:PATH=/usr/lib/python3/dist-packages/numpy/core/include \
-DCMAKE_BUILD_TYPE:STRING=Release
------------------------8<---------------------

which also looks reasonable. However, there is a module to be compiled
using f2py, which then fails, because it takes the default f2py instead
of the one that is specific for Python 3.13. This currently results in a
module compiled for Python 3.12, and so the build for 3.13 fails.

I am now unsure where the bug is:

* in Python's "build" module?
* in the "meson" Python module?
* in pybuild?
* numpy?
* upstream?
* Or must I set (or install) something to make it running?

Build log is f.e.
https://salsa.debian.org/debian-astro-team/pybdsf/-/jobs/6612895

Best regards

Ole

[Timo Röhling]

Hi Ole,

Post by Ole Streicher
Build log is f.e.
https://salsa.debian.org/debian-astro-team/pybdsf/-/jobs/6612895

The problem is most likely caused by "find_package(F2PY)", which
does not take different Python versions into account [1].

Debian ships with f2pyX.Y scripts for each supported Python version.
Alternatively, the example code in the NumPy documentation [2]
invokes f2py via "${Python_EXECUTABLE} -m numpy.f2py", which should
also work with skbuild.


Cheers
Timo

[1]
https://salsa.debian.org/python-team/packages/scikit-build/-/blob/debian/master/skbuild/resources/cmake/FindF2PY.cmake?ref_type=heads#L69
[2] https://numpy.org/doc/1.26/f2py/buildtools/cmake.html

[Ole Streicher]

Hi Timo,

Post by Ole Streicher
Build log is f.e.
https://salsa.debian.org/debian-astro-team/pybdsf/-/jobs/6612895

The problem is most likely caused by "find_package(F2PY)", which does
not take different Python versions into account [1].

This is indeed the case. But shouldn't that be adjusted for Debian (or
even upstream)? Setting f2py different from the Python minor version
seems a bug to me.

At the end, everybody tyrying to run a project that uses
"find_package(F2PY)" for a non-default Python version on Debian will
stumble upon it, which is a bit contrary to the idea of having CMake
figuring the required configuration.

Best

Ole

[Andrey Rakhmatullin]

Post by Ole Streicher

Post by Ole Streicher
Build log is f.e.
https://salsa.debian.org/debian-astro-team/pybdsf/-/jobs/6612895

The problem is most likely caused by "find_package(F2PY)", which does
not take different Python versions into account [1].

This is indeed the case. But shouldn't that be adjusted for Debian (or
even upstream)? Setting f2py different from the Python minor version
seems a bug to me.

If the upstream of f2py doesn't provide f2pyX.Y binaries, the only way to
adjust this seems to be switching FindF2PY.cmake to run it via `pythonX.Y
-m`.

Post by Ole Streicher
At the end, everybody tyrying to run a project that uses
"find_package(F2PY)" for a non-default Python version on Debian will
stumble upon it, which is a bit contrary to the idea of having CMake
figuring the required configuration.

Sure, if the FindF2PY.cmake upstream wants this use case to be supported
by it.