Windows wheels have incorrect platform tags

[freakboy3742]

Describe the bug

The Toga Winforms wheels are tagged py3-none-any. However, they contain binary components (DLLs for WebView compatibility). They should be tagged as binary wheels.

This means there's nothing preventing the installation of Windows wheels on macOS or Linux, despite the fact that there are binary components that aren't compatible with non-Windows platforms.

Steps to reproduce

1. Download the toga-winforms wheel
2. Observe that it contains binary components.

Expected behavior

The wheel should have a platform tag. Technically, I think it should be py3_none_win_amd64, but I'm not sure how well that will work with pip - it may be necessary to use a tag like cp39_abi3_win_amd64 to fake "Python version doesn't matter, but it's Windows".

There should also be separate wheels for _win_amd64, _win32 and _win_arm64.

Screenshots

No response

Environment

• Operating System: Windows
• Python version: All

Logs

Additional context

This isn't causing any problems at present, but it does mean that Windows apps are larger than they need to be, and is providing a misleading compatibility tag in published artefacts.

This doesn't affect other platforms, and the wheels are pure Python wheels. They won't actually run on other platforms, but that will be reported as a runtime issue when FFI interfaces fail to find the required system components.

[freakboy3742]

As prior art: the PySDL2-DLL package has a similar requirement, and manages the task with a setup.py hack

It also confirms that py3-none-win_amd64 wheels will work.

[freakboy3742]

Another approach: wheel has unpack, pack and tags subcommands that can be used to tweak the content and tagging of a wheel.

[mhsmith]

Technically, I think it should be py3_none_win_amd64, but I'm not sure how well that will work with pip

I think it works fine – this case is explicitly mentioned in the wheel tag spec, and there's a precedent in packages such as cmake.