Wheel builds and tests are passing here (🎉): https://github.com/PyWavelets/pywt/actions/runs/9308866217/job/25623111691

There is one thing to be noted, though. Maybe this is a valid bug that we either need to raise upstream, or I did some invalid tinkering: none of the commands as follows: pytest --pyargs pywt / pytest pywt / pytest {project} / pytest {package} seem to be working, and that's probably one of the downsides of not having an src layout for PyWavelets (side note, should we switch to it for v1.6.1 or v1.7.0? I feel it should be trivial). Regular pytest also does not work right now and it picks up the wrong pytest on the PATH, which I already know is coming from pyodide/pyodide#4802. Therefore, I tried python -m pytest <...> commands, which all failed because they tried to load the extension somehow from the root directory and not cibuildwheel's venv (or I'm using the replaceable markers {package} and {project} incorrectly). Lastly, the pywt.test() API is the only invocation method that ended up in success, so, we can go with that for now – I have no strong opinions about this choice.

P.S. I was confused as to why the wheel gets retagged with the ABI tag pyodide_2024_0 rather than emscripten_3_1_58 but I later realised that this came from https://github.com/pypa/cibuildwheel/pull/1456/files#diff-2b69544a3d026eefdb78165338361dd2def21bc816d39774b9523265d1c84481R243-R248 and pyodide/pyodide#4777 😅

none of the commands as follows: pytest --pyargs pywt / pytest pywt / pytest {project} / pytest {package} seem to be working

Isn't that a matter of doing cd doc && pytest --pyargs pywt or some such thing?

I thought so too, it's the usual pytest peculiarity because it can't find the shared objects to import from the source folder. However, the cibuildwheel documentation says that the package to be tested is imported from a new virtual environment where it gets installed at the time of testing, and not from the CI workspace directory for exactly this reason, so I expected that it would avoid that