libzmq no longer supports binaries for Windows, and has removed support for tweetnacl.
This may mean that Windows wheels will lose CURVE, or we have to get binaries elsehwere, or run our own builds of libzmq to bundle, which I suspect would be highly likely to get the wrong DLL dependency bundling.
Maybe related to #1902 since windows arm builds ought to work, I think?
Increasingly, I think the way we do bundling should change due to this, but what we have now is so brittle and works in so many untestable cases that I dread it.
I think:
it should download and install libsodium and libzmq, not bundle sources
those installers should use their own installation scripts (./configure or cmake), not setup.py
(maybe) take the opportunity to move to a modern build tool, like scikit-build-core or meson.
Pros:
This would eliminate much of the complexity of setup.py (trading it for as-yet-unidentified complexity of new tools)
Running their own builds, would eliminate maintenance of the include_{platform} files
Download & install means no more bundling sources
Cons:
New build tooling will inevitably break some installs, and cause maintenance trouble for some time, especially since I have hardly any experience with scikit-build-core, and none with meson
Downloading external dependencies at install time means pyzmq can't install from a single tarball without Internet if libzmq is not found (decreasingly relevant, but not irrelevant)
libzmq no longer supports binaries for Windows, and has removed support for tweetnacl.
This may mean that Windows wheels will lose CURVE, or we have to get binaries elsehwere, or run our own builds of libzmq to bundle, which I suspect would be highly likely to get the wrong DLL dependency bundling.
Maybe related to #1902 since windows arm builds ought to work, I think?