Skip to content

Rebuild for python 3.15 - #396

Closed
h-vetinari wants to merge 16 commits into
conda-forge:mainfrom
h-vetinari:py315
Closed

h-vetinari wants to merge 16 commits into
conda-forge:mainfrom
h-vetinari:py315

Conversation

@h-vetinari

Copy link
Copy Markdown
Member

For demonstrating the migrator

…026.09.01.16.28.00

Other tools:
- conda-build 26.7.1
- rattler-build 0.75.0
- rattler-build-conda-compat 1.4.19
@conda-forge-admin

Copy link
Copy Markdown
Contributor

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

…026.09.01.16.28.00

Other tools:
- conda-build 26.7.1
- rattler-build 0.75.0
- rattler-build-conda-compat 1.4.19
@h-vetinari

Copy link
Copy Markdown
Member Author

Hm, a single error. The test in question has no discernible dependency on the python version, so this is possibly relevant with respect to packaging changes:

In $PREFIX/lib/python3.15/site-packages/conda-site.pth: $PREFIX/lib/python/site-packages does not exist; skipping sys.path append

CC @isuruf

Details
 │ ________________________ test_freethreading_compatible _________________________
 │ [gw2] linux -- Python 3.15.0 $PREFIX/bin/python
 │ hello_world_f90 = local('/tmp/pytest-of-rattler/pytest-0/popen-gw2/hello.f90')
 │ monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7fa30ead66d0>
 │     @pytest.mark.skipif((platform.system() != 'Linux') or sys.version_info <= (3, 12),
 │                         reason='Compiler and Python 3.12 or newer required')
 │     def test_freethreading_compatible(hello_world_f90, monkeypatch):
 │         """
 │         CLI :: --freethreading_compatible
 │         """
 │         ipath = Path(hello_world_f90)
 │         monkeypatch.setattr(sys, "argv", f'f2py -m blah {ipath} -c --freethreading-compatible'.split())
 │     
 │         with util.switchdir(ipath.parent):
 │             compiler_check_f2pycli()
 │             cmd = f"{sys.executable} -c \"import blah; blah.hi();"
 │             if NOGIL_BUILD:
 │                 cmd += "import sys; assert sys._is_gil_enabled() is False\""
 │             else:
 │                 cmd += "\""
 │             cmd_run = shlex.split(cmd)
 │             rout = subprocess.run(cmd_run, capture_output=True, encoding='UTF-8')
 │             eout = ' Hello World\n'
 │             assert rout.stdout == eout
 │             if "LSAN_OPTIONS" not in os.environ:
 │ >               assert rout.stderr == ""
 │ E               AssertionError: assert 'In /home/con...path append\n' == ''
 │ E                 
[3](https://github.com/conda-forge/numpy-feedstock/actions/runs/33557186125/job/100020945832?pr=396#step:6:5837)
 │ E                 + In $PREFIX/lib/python3.15/site-packages/conda-site.pth: $PREFIX/lib/python/site-packages does not exist; skipping sys.path append
 │ cmd        = '$PREFIX/bin/python -c "import blah; blah.hi();"'
 │ cmd_run    = ['$PREFIX/bin/python', '-c', 'import blah; blah.hi();']
 │ eout       = ' Hello World\n'
 │ hello_world_f90 = local('/tmp/pytest-of-rattler/pytest-0/popen-gw2/hello.f90')
 │ ipath      = PosixPath('/tmp/pytest-of-rattler/pytest-0/popen-gw2/hello.f90')
 │ monkeypatch = <_pytest.monkeypatch.MonkeyPatch object at 0x7fa30ead66d0>
 │ rout       = CompletedProcess(args=['$PREFIX/bin/python', '-c...uild_artifacts/test/test_numpyDaaYxR/test_run_env/lib/python/site-packages does not exist; skipping sys.path append\n')
 │ ../test_run_env/lib/python3.15/site-packages/numpy/f2py/tests/test_f2py2e.py:858: AssertionError
 │ ----------------------------- Captured stdout call -----------------------------
 │ Cannot use distutils backend with Python>=3.12, using meson backend instead.
 │ Using meson backend
 │ Will pass --lower to f2py
 │ See https://numpy.org/doc/stable/f2py/buildtools/meson.html
 │ Reading fortran codes...
 │ 	Reading file '/tmp/pytest-of-rattler/pytest-0/popen-gw2/hello.f90' (format:free)
 │ Post-processing...
 │ 	Block: blah
 │ 			Block: hi
 │ Applying post-processing hooks...
 │   character_backward_compatibility_hook
 │ Post-processing (stage 2)...
 │ Building modules...
 │     Building module "blah"...
 │     Generating possibly empty wrappers"
 │     Maybe empty "blah-f2pywrappers.f"
 │ 		Creating wrapper for Fortran function "hi"("hi")...
 │         Constructing wrapper function "hi"...
 │           hi = hi()
 │     Wrote C/API module "blah" to file "./blahmodule.c"
 │     Fortran 77 wrappers are saved to "./blah-f2pywrappers.f"
[4](https://github.com/conda-forge/numpy-feedstock/actions/runs/33557186125/job/100020945832?pr=396#step:6:5868)
 │ The Meson build system
 │ Version: 1.12.0
 │ Source dir: /tmp/tmp71t2khmt
 │ Build dir: /tmp/tmp71t2khmt/bbdir
 │ Build type: native build
 │ Project name: blah
 │ Project version: 0.1
 │ Fortran compiler for the host machine: $PREFIX/bin/x86_64-conda-linux-gnu-gfortran (gcc 15.3.0 "GNU Fortran (conda-forge gcc 15.3.0-4) 15.3.0")
 │ Fortran linker for the host machine: $PREFIX/bin/x86_64-conda-linux-gnu-gfortran ld.bfd 2.46.1
 │ C compiler for the host machine: x86_64-conda-linux-gnu-cc (gcc 15.3.0 "x86_64-conda-linux-gnu-cc (conda-forge gcc 15.3.0-4) 15.3.0")
 │ C linker for the host machine: x86_64-conda-linux-gnu-cc ld.bfd 2.46.1
 │ Host machine cpu family: x86_64
 │ Host machine cpu: x86_64
 │ Compiler for C supports arguments -fno-strict-aliasing: YES 
 │ Program $PREFIX/bin/python found: YES ($PREFIX/bin/python)
 │ Found pkg-config: YES ($PREFIX/bin/pkg-config) 0.29.2
 │ Run-time dependency python found: YES 3.15
 │ Library quadmath found: YES
 │ Build targets in project: 1
 │ Found ninja-1.13.2 at $PREFIX/bin/ninja
 │ ninja: Entering directory `/tmp/tmp71t2khmt/bbdir'
 │ [1/7] Scanning target blah.cpython-315-x86_64-linux-gnu for modules
 │ In $PREFIX/lib/python3.15/site-packages/conda-site.pth: $PREFIX/lib/python/site-packages does not exist; skipping sys.path append
 │ [2/7] Generating dynamic dependency information for target blah.cpython-315-x86_64-linux-gnu
 │ In $PREFIX/lib/python3.15/site-packages/conda-site.pth: $PREFIX/lib/python/site-packages does not exist; skipping sys.path append
 │ [3/7] Compiling Fortran object blah.cpython-315-x86_64-linux-gnu.so.p/blah-f2pywrappers.f.o
 │ [4/7] Compiling Fortran object blah.cpython-315-x86_64-linux-gnu.so.p/hello.f90.o
 │ ../hello.f90:1:0:
 │     1 | function hi()
 │ Warning: Return value of function 'hi' at (1) not set [-Wreturn-type]
 │ [5/7] Compiling C object blah.cpython-315-x86_64-linux-gnu.so.p/blahmodule.c.o
 │ [6/7] Compiling C object blah.cpython-315-x86_64-linux-gnu.so.p/f4767453276429db3f06205abe43a087f545cab3_.._.._f2py_src_fortranobject.c.o
 │ [7/7] Linking target blah.cpython-315-x86_64-linux-gnu.so
 │ INFO: autodetecting backend as ninja
 │ INFO: calculating backend command to run: $PREFIX/bin/ninja -C /tmp/tmp71t2khmt/bbdir
 │ ----------------------------- Captured stderr call -----------------------------
 │ In $PREFIX/lib/python3.15/site-packages/conda-site.pth: $PREFIX/lib/python/site-packages does not exist; skipping sys.path append
 │ In $PREFIX/lib/python3.15/site-packages/conda-site.pth: $PREFIX/lib/python/site-packages does not exist; skipping sys.path append

@h-vetinari

Copy link
Copy Markdown
Member Author

Hm, and windows is not happy at all:

..\meson.build:1:0: ERROR: Cython requires python3 dependency for link testing, but it could not be found

This reminds me of conda-forge/python-feedstock#349, but looks unrelated upon closer inspection. AFAICT this does not come from numpy's build, but from meson's cython handling. So it sounds like meson now doesn't know how to deal with our more unixy python on windows...

@rgommers

rgommers commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

The Cython detection issue is mesonbuild/meson#15740. Adding pkg-config as a test dependency in the recipe here should make that go away, and is a good workaround for the issue I believe.

The test_freethreading_compatible failure can be skipped for the time being, that should not be a numpy-specific problem.

@h-vetinari

Copy link
Copy Markdown
Member Author

The Cython detection issue is mesonbuild/meson#15740. Adding pkg-config as a test dependency in the recipe here should make that go away, and is a good workaround for the issue I believe.

Thanks for chiming in, and the useful reference. However, this is happening at build time, where pkg-config is already present. W.r.t. the other work-around I saw mentioned in the issue -- setting PKG_CONFIG_PATH=$CONDA_PREFIX/lib/pkgconfig -- I don't know where to point it to, given that our python builds on windows (also pre-3.15) don't have pkgconfig metadata.

@h-vetinari

Copy link
Copy Markdown
Member Author

My current hypothesis is that this is more likely due to how for py = import('python').find_installation(pure: false), meson looks for a ~complete python setup, and is not ready for the case that Python.h is in

%PREFIX%\include\python\Python.h

rather than in

%PREFIX%\include\Python.h

@rgommers

rgommers commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Why did the file layout change in 3.15?

@h-vetinari

Copy link
Copy Markdown
Member Author

Because of CFEP-27. Here's a preview of the release blog post that has a shorter summary.

@h-vetinari

Copy link
Copy Markdown
Member Author

Here's a relevant comment from the PR that added the CFEP

Some tools might have these path (semi-)hardcoded in, so it'd probably make sense to look out for possible downstream tests, e.g., CMake's FindPython could be one of those cases.

@isuruf: Most tools use sysconfig to get these values. For eg: CMake and setuptools When it is not, we can patch them first and send PRs upstream to use sysconfig.

Looks like we'll have to do that for meson...

@rgommers

rgommers commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Ah okay. That that likely has nothing to do with either NumPy or Cython - Python.h got moved, and the Cython sanity check is simply the first thing looking for it.

Some useful cleanups from this exercise longer-term it looks like.

@h-vetinari

Copy link
Copy Markdown
Member Author

So meson detects Python.h purely based on whether the compiler can find it. From that POV, I don't understand why adding the right include directory to CFLAGS doesn't work; except if for some reason, the cython check runs so early that CFLAGS hasn't been processed yet?

@rgommers

rgommers commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Not just order, all compiler sanity checks don't take environment variables into account by design I believe. This is because CFLAGS can contain a lot of stuff that may throw off checks.

@h-vetinari

Copy link
Copy Markdown
Member Author

Hm. The docs say:

Note that if you have a single prefix with all your dependencies, you might find it easier to append to the environment variables C_INCLUDE_PATH with GCC/Clang and INCLUDE with MSVC to expand the default include path, and LIBRARY_PATH with GCC/Clang and LIB with MSVC to expand the default library search path.

6b273d6 was pointing to the wrong folder, so let me try that again

@h-vetinari

Copy link
Copy Markdown
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants