Hmm. meson can be installed by pip, but what do we do about ninja? It is a hard requirement to run meson. I guess we should skip the build-a-module tests if ninja is not installed.

Edit: nvrmind: ninja can be pip installed too!

Any ideas how to avoid pip installing a package in a requirements file on pyodide? This works (will skip installing ninja) on ubuntu

ninja ; sys_platform != "linux"

but this seems to not work on pyodide

ninja ; sys_platform != "emscripten"

even though the sys.platform is emscripten

I think ninja should be packaged in Pyodide, and until that happens I'd just skip the tests for IS_WASM. Cc @hoodmane for visibility/opinion.

The relevant tests are skipped. The problem is that pip install -r test_requirements.txt is failing on pyodide (before testing begins), since ninja cannot be installed. I could remove it from test_requirements.txt and install manually in all the other CI runs, but that seems wrong.

Ah, that makes sense. It should already be present in most all CI runs (except for the ones with build isolation perhaps), because it's needed for building. It falls in the same category as compilers, pkg-config, etc. - I'd say it should not be in test_requirements.txt because ninja is not a Python package and you'd preferably get it from your system package manager (it being packaged on PyPI is a hack; meson-python has an elaborate workaround to only install it if it's not already present on the system).

tl;dr this is an Ubuntu job, so just install it with apt?

this is an Ubuntu job, so just install it with apt?

Kind of. "this" is also all wheel builds, which build in an isolated environment and then test.

ninja is needed a bit everywhere. While it can be installed by apt and choco, it is not clear how to install it on macOS. Apparently there is no yum package of that name available in the manylinux2014_i386 image. So I still did pip install in places where I was too lazy to work out an alternative.

So I still did pip install in places where I was too lazy to work out an alternative.

That sounds fine to me.

Looking more closely at the ninja PyPI package, it seems like a valid wheel solution to provide a binary for all platforms. It is a shame I needed to add it everywhere pip install -r test_requirements.txt is used instead of putting this inside test_requirements.txt

ninja ; sys_platform != "emscripten"

This is ready for review:

• move cython and c-extension compilation to meson
• add a c++ cython build test to the existing ones using the nprandom static library
• remove a python3.9 azure job
• add a spin -m full command to run slow tests

On the topic of

ninja ; sys_platform != "emscripten"

I've run into the same problem while working on pypa/cibuildwheel#1456 and I would like to fix it soon. There's a lot of complexity involved in convincing pip to behave correctly since it needs to run on the host linux Python but install stuff for emscripten Python. I think the correct way to fix this is to use PYTHONPATH to add customized versions of the standard library modules platform.py and sysconfig.py but it is a bit tricky to get right.

time spin test shows that the default test suite run goes from 7min03 to 2min47, which is nice for usability.

I addressed the review comments, CI is passing.

CI is passing.

It looks very red to me.

I think you forgot to commit the new meson.build file?

I think you forgot to commit the new meson.build file?

Thanks. Committed now, I guess I should refresh (f5) before jumping to conclusions.

We may want to backport some of this to 1.26, so marking.

We may want to backport some of this to 1.26, so marking.

Seems we don't need it, so removing label.