test_package: build the WASM wheel URL with the normalised version - #9443

Follow-up to #9430, where TestPackageSupportedPlatforms::test_run was skipped with "Re-enable when builds are fully operational again". The skip has since been replaced by a non-strict xfail in 5aaf210. This PR fixes a real bug the xfail was masking, and reports honestly on what is still missing.

Mechanism

WASM_TEMPLATE interpolated BINARY_VERSION read verbatim from src/ifcopenshell-python/Makefile, which is 0.9.0alpha0. Wheels are not named that way. pyodide/build_pyodide.sh normalises the version to the canonical PEP 440 form before building:

VERSION=`python3 -c "from packaging.version import Version; print(Version('$VERSION'))"`

and the Makefile itself carries the same normalisation for its own packaging at line 5:

VERSION_PYTHON:=$(shell sed 's/alpha/a/' ../../VERSION)

So every pyodide wheel on the bucket is named ifcopenshell-0.9.0a0+<sha>-..., and the URL the test built could never resolve, whatever commit is pinned. The platform zips are unaffected, they really are named with the raw 0.9.0alpha0.

find_make_var("VERSION_PYTHON") cannot be used to get the normalised value. It returns the unevaluated string $(shell sed 's/alpha/a/' ../../VERSION), and it is derived from VERSION rather than from the pinned BINARY_VERSION, which can lag it. The substitution is therefore applied in the test, mirroring what the Makefile does.

pyodide/pack_wheel.py::get_wheel_url builds the same URL from the same variable and had the same defect, so it is fixed in the same commit. It is the download path that #9427 extends.

URL resolution, measured with HEAD requests today

All 19 URLs the test builds, before and after.

The platform half of the test is fully satisfied at the pinned BUILD_COMMIT:=ad113e1, including all five Python versions and macosm164, so the stale macos64 entry removed in 66126d2 was the last blocker there.

What still blocks removing the xfail

The version fix alone is not enough, so the xfail added in 5aaf210 is left in place. No pyodide wheel exists for ad113e1 under either spelling of the version. What is on the bucket for 0.9.0:

Two things follow.

1. Build IfcOpenShell WASM / Pyodide is workflow_dispatch only and stamps ${GITHUB_SHA:0:7} into the wheel name, so the WASM artifact is pinned by whichever commit that workflow last ran on. It did run after ad113e1, on 2026-08-26 and 2026-08-28, but never on ad113e1 itself. The test can only go green when a WASM build exists at the pinned commit, either by dispatching the workflow at ad113e1 or by bumping BUILD_COMMIT to a commit where all five build workflows ran.

2. The two most recent WASM builds are tagged pyemscripten_2025_0_wasm32, not pyodide_2025_0_wasm32, so WASM_PLATFORM in the test would not match them either. pyodide/pack_wheel.py sets USE_LEGACY_PLATFORM=1 for exactly this reason, with the comment "pyodide 0.34.1 introduced new tag for wheels pyemscripten, which doesn't work with pyodide itself yet" (Bump pyodide release to support pyemscripten tag pyodide/pyodide#6177). pyodide/build_pyodide.sh, which is what the CI workflow runs, does not set it. That looks like an unintended tag change on the CI side rather than something the test should follow, but it needs a decision from whoever owns the pyodide build before the pin is moved.

So the sequence to get this test green: dispatch Build IfcOpenShell WASM / Pyodide at the commit that will be pinned, with the legacy platform tag, then bump BUILD_COMMIT and drop the xfail. The xfail condition is already keyed to BUILD_COMMIT:=ad113e1, so it clears itself on the next bump.

To make the next failure self-explanatory, the assertion now names the missing artifacts:

E       AssertionError: Build artifacts are not published:
E         https://s3.amazonaws.com/ifcopenshell-builds/ifcopenshell-0.9.0a0%2Bad113e1-cp313-cp313-pyodide_2025_0_wasm32.whl

Before this PR the same message would have pointed at 0.9.0alpha0, an artifact that never exists, which is a misleading thing to hand the next person bumping the pin.

v0.8.0

v0.8.0 has the same code shape but not the same bug in practice: its BINARY_VERSION is 0.8.6, already canonical PEP 440, so the substitution is a no-op there and ifcopenshell-0.8.6%2Be333c1c-cp313-cp313-pyodide_2025_0_wasm32.whl resolves 200. Nothing to fix on v0.8.0 today, but the same latent trap is there if that branch ever pins an alpha version. Not touched in this PR.