@hoodmane Any ideas as to the problem?

Copying the traceback for searchability:

Run pyodide build -Cbuild-dir=build -Csetup-args="--cross-file=$PWD/tools/ci/emscripten/emscripten.meson.cross" -Csetup-args="-Dblas=none" -Csetup-args="-Dlapack=none"
Downloading xbuild environment                                                  
Installing xbuild environment                                                   

Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.11.3/x64/lib/python3.11/site-packages/pyodide_build/pypabuild.py", line 84, in _runner
    env["BUILD_ENV_SCRIPTS_DIR"] = isolated_build_env._scripts_dir
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: '_DefaultIsolatedEnv' object has no attribute '_scripts_dir'

This is a generic problem; the same failure is visible on the PyWavelets repo.

@agriyakhetarpal would you be able to investigate this issue?

Thanks, @rgommers – I indeed noticed this and I was going to open an issue today here, someone else got towards doing it first :) I'm happy to investigate further.

I cannot say for sure, but most likely it's coming from the build v1.2 release that came out a few days ago, so adding an upper bound should work as a temporary solution.

Sounds good, and sounds like the right diagnosis. Let's add the upper bound first to unbreak things, and then investigate further?

It looks like _scipts_dir changed to scripts_dir in pypa/build@f454933.

I'll make a note about this on the Pyodide issue tracker too. Maybe keeping build and other build frontends pinned to a specific version per Pyodide version and therefore Emscripten version (though there are plans to change the latter in pyodide/pyodide#4557) would prevent further breakage.

I have tried a few things, and the _scripts_dir to scripts_dir change did not work as such. I'm unsure how easy it is to patch the xbuildenv that Pyodide downloads from GitHub releases before setting up a build environment. I'm almost sure that the recent build releases broke the workflow, but I'll be looking to figure out now why a new version of build seems to get installed and where, thereby causing conflicts with pyodide build – also, the pypabuild.py file itself uses another file vendor/_pypabuild.py, which makes it all the more confusing as to what is happening.

This should be fixed by pyodide/pyodide#4653. I guess pinning build == 1.1 in your requirements files works for existing versions, I don't know if we want to backport a release to 0.25.x @ryanking13?

Thank you for the quick fix, @hoodmane and @ryanking13! I'll patch those changes in when it gets merged.

To be clear, it was just @ryanking13 I am just reporting what he did =)

Yes, I think we should make a backport release as this will break everywhere. Until that, please pin the build version to < 1.2.0.

Pyodide 0.25.1 is out, a preliminary PR is at #26185. @agriyakhetarpal I needed to disable the patching, both chunks were failing to apply. Not sure what changed.