Fix Windows wheel architecture detection

[CAOShurong]

Fixes #485.

With _soundfile_data initialized, the default Windows source build looks for libsndfile_64bit.dll or libsndfile_32bit.dll, while the bundled libraries are named libsndfile_x64.dll and libsndfile_x86.dll. The resulting wheel omits the DLL. Select x64, x86 or arm64 from the interpreter platform, using the same mapping as soundfile.py, and derive the wheel tag from that selection. Explicit cross-build targets remain supported.

For x64 Python running on ARM64 Windows, the interpreter platform is win-amd64: the package needs the x64 DLL and win_amd64 tag, even when platform.machine() reports ARM64. The parameterized tests cover that case and x86 Python on ARM64; native execution on those hosts was not tested locally.

The packaging tests stub the build-tool entry points instead of importing setuptools at collection time. This fixes the reported CI failure in environments where build dependencies exist only inside pip's isolated build environment.

Validation of the follow-up: 19 packaging cases and the full 358-test suite pass on Windows / Python 3.13 in a fresh environment without setuptools. All 358 tests also pass against a non-editable wheel installed outside the source checkout; the wheel contains libsndfile_x64.dll. Both full runs report 16 CFFI callback warnings. New upstream CI is pending.

[bastibe]

Perhaps I'm not understanding the issue. We have a test suite for Windows x86, x64, and arm64, and they are all green. I have personally tested each release on Windows x64 and arm64, which also seems to work.

Could you explain specifically which combinations of features does not work?

[CAOShurong]

The failing case is a locally built, non-editable wheel with default settings, not the published release wheels.

On current master bffe99d9, Windows x64 / CPython 3.13, with _soundfile_data initialized and neither PYSOUNDFILE_* variable set:

python -m pip wheel . --no-deps --no-build-isolation -w dist

The resulting soundfile-0.14.0-py2.py3-none-win_amd64.whl is 37,965 bytes and contains no DLL. Installing it outside the checkout makes import soundfile fail with 0x7e. On the same base, explicitly setting PYSOUNDFILE_PLATFORM=win32 and PYSOUNDFILE_ARCHITECTURE=x64 produces a wheel containing libsndfile_x64.dll; import and a WAV roundtrip pass. This PR's default build gives the same successful result, without those overrides. Both installed outcomes were repeated.

The existing CI installs --editable, leaving the source-tree DLL accessible; the baseline source import and WAV roundtrip also pass here. build_wheels.py explicitly sets the platform and architecture, so release builds bypass the faulty default selection too. That is consistent with the green tests and working release wheels you describe.

Native x86/ARM64 runs and the reporter's original uv project were not tested; the additional architecture cases are setup-selection regressions, not native-platform results.

[bastibe]

So the official wheels I build are fine, but your issue is, that the build script could be improved?

Presumably you stumbled upon this while trying to build your own wheels. Why did you want to do that, is there anything wrong with the official wheels?

[CAOShurong]

Yes—this is a defect in the default source-build path, not a claim that the official release wheels are broken.

The motivating case is #485: uv add "git+https://github.com/bastibe/python-soundfile" builds a wheel from the Git source, and the reporter found that it omitted the Windows DLL. The local pip wheel build was a reproducer for that path, not a workaround for an official wheel. The release script's explicit platform/architecture settings already avoid the faulty default selection.

The PR makes that default selection work for source installations too. The original uv project itself was not tested here.

[bastibe]

The tests are cool, thank you. However, they currently break the CI, which is of course not acceptable.

I don't think I understand the purpose of the changes to setup.py, to be honest. And they seem to introduce a regression for x64 Python running on Arm Windows (which is very common).

[CAOShurong]

The CI failure was ModuleNotFoundError: setuptools during test collection. The packaging tests now stub that build-time entry point, as they already did for wheel. The full suite passes all 358 tests both from source and against a non-editable wheel, in a fresh environment confirmed to have no setuptools installed.

For x64 Python on ARM64 Windows, sysconfig.get_platform() describes the interpreter (win-amd64), so this selects libsndfile_x64.dll and the win_amd64 wheel tag. That is the same selection already used by soundfile.py; using the host's machine() instead would choose the ARM64 tag for an x64 interpreter. The tests cover this combination and now also x86 Python on ARM64. These are simulated selection tests; native ARM64-host execution was not performed locally.