1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.PYTHON

  • f2py problem with Multi-Python (and Ninja)

    From Ole Streicher@21:1/5 to All on Mon Nov 18 14:10:01 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Timo =?utf-8?Q?R=C3=B6hling?=@21:1/5 to All on Mon Nov 18 15:20:01 2024
    Hi Ole,

    * Ole Streicher <[email protected]> [2024-11-18 13:40]:
    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


    --
    ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
    ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
    ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
    ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAmc7S2MACgkQzIxr3RQD 9Mrhxg//R1sYM8HvhZrqVQmlxbtEW99nrpabx5QngO3gKogwYJMB1lTue0LsAvIm SrytQTjttauGXNxXV0q6V9lSfjVpwm6kRqwYF2/UEXqjiTXZXaqovnu82PwQ1FfB bjqfqfGV1XPZd1F6f8VMGIKsZHDi1dGg9YXLrcK8yn2O9ZW1Mf4v7/l6kFKCO8pc 0CgJNYc8wVYXBgsnrATTX4PaPwfil/8+clHutapu1D4r5HFF5R/uzkY5G2ihI68m 5DVEsiebGyH3h/gLd91gRAUR/kfSns0Ak80Xsza/CgHE9+jriC4IMkEyYJI6r/xX 4RkGHZxDvbLLuZ7kVSUt8B5AAL5rki0KDETSv4PlEKl
  • From Ole Streicher@21:1/5 to [email protected] on Mon Nov 18 16:30:01 2024
    Hi Timo,

    Timo Röhling <[email protected]> writes:
    * Ole Streicher <[email protected]> [2024-11-18 13:40]:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrey Rakhmatullin@21:1/5 to Ole Streicher on Mon Nov 18 17:50:02 2024
    On Mon, Nov 18, 2024 at 04:07:32PM +0100, Ole Streicher wrote:
    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`.

    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.

    --
    WBR, wRAR

    -----BEGIN PGP SIGNATURE-----

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmc7bsktFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh TC0P/29kiA++gMwhEsD+l3cgGL52V6sD72foQgJMwdbO56kSbyVKHqlFH6t1pVpG w3TDJ5YZBEXizg4aGDeEyFuo9OkjoTrU7UyVAdcYOcBI4srCw6156cHOY/7FaGsb Fnb1d5JkFcPuGf3tZANgRKMzUAtkjal+6JbNDhFwMoxko3zjpFyNvPUwXvVT0mxm mHo77j0V+56+ltyM+jg+/9vUr12C3jZwqvN5DRp1sik8Id87BIVzccY43rQLc7Vd 0x9UQZx3k1/6Kdc9O7bpdbBqEJpEaopSrWZxITaiGlEB6GlVte66JFC4JEWXVsb2 YxMUuapeLXLBbmVFizUEouhuSiqgUL/Ckw3YXZiwm7seeh8VOAzjlLY7u3hlxG6O gzhiyxpN6jo5nbPkYdArCpKwj2pnRZeZkUeNaQ7dsDYlMdmljwb6dRoyU9mrxhGt sRK1UlnyUw+aT3xhc61jCru4tq5CCiOe84Pgm+zzZXtJhLgjcWWrguixhvPUCmEO chuo3XwkwXIPxI2gqgjrIaWDzS4iU42W2D2iwBdRf5aQ0UdRoz7O5drWE559CMWh lU3zUHSJDTCtVN8iUHtf8g2zC/mc2S4QeZ1famGQuh1PedI4dcCeyItBkyfgdZlJ WYBWfBi6Gm3vC4MHf+SEc9ZjSwnm9Ai0uylDfOka3s4UlhW7
    =LxUG
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)