More detailed wheel tags on Windows platform regarding MSVC / MinGW differences

Ideas
1

Hi everyone,

I noticed that wheel tags on Windows currently seem to include only the basic platform architecture, for example:

somepkg-cp312-cp312-win_amd64.whl
somepkg-cp312-cp312-win_arm64.whl

However, packages built with MSVC (Microsoft Visual C++) and packages built with MinGW can have significant compatibility differences.

Should there be more specific tags to distinguish these cases?

For example, something like:

somepkg-cp312-cp312-win_amd64_msvc.whl
somepkg-cp312-cp312-win_amd64_mingw.whl

Linux already has a distinction between manylinux and musllinux tags which introduced by PEP 656.

2

packages built with MSVC (Microsoft Visual C++) and packages built with MinGW can have significant compatibility differences.

What differences are there?
If you need a different build of Python to load MinGW packages, you probably want to add a new tag like mingw, rather than change the existing tag. That would mean a PEP like PEP 656 – but simpler if this doesn’t need its own version number.
If you don’t need a different build of Python, wheel tags probably aren’t the right place for this info.

1 Like
3

Wheel variants might be a good fit for this, once they are standardised.

1 Like
4

Yes, I agree that the biggest difference is “can this package be used on Python that built with the same compiler”.

Nowadays cpython interpreter & most 3rd party packages are compiled by MSVC. But there is still some scenarios that python developers work on mingw / msys2 environment. Those developer may benefit from explicit tag info. Admittedly, such scenarios are relatively rare.

5

I’ll dig deeper into this. Thank you very much for the pointer！

6

Hang on. If you’re using msys2, that’s a cygwin variant, so it needs a cygwin build of Python, not the standard python.org build. That is a different platform, although it’s not supported by the Python core team, so there’s no official platform tags for it.

1 Like
7

Yes, and I also noticed that some msys2 distributed packages have sub-variants (like “-ucrt”). It seems complicated. May be in the future, a standarlized wheel variant specs can address this in a unified way.

8

No, it doesn’t. The msys2 environment is used to make native Windows binaries. You can use msys2 to build extension modules that work with MSVC-compiled CPython. You should not need to care whether MSVC or msys2/mingw was used to build the binaries in a wheel.

Matching the C runtime (ucrt vs msvcrt.dll) is apparently important although I’ve seen mismatched wheels that were widely used and seemed to work fine so I’m not sure when exactly it breaks. I don’t think tags are needed for the C runtime though: normal CPython builds use UCRT so all Windows wheels should do the same.

1 Like
9

The complexity about Windows compiler & C runtime exceeds my initial thought.

I think, for a not-too-bad solution, maybe python prebuild libraries on msys2 should be distributed as msys2-specific software packages (which should be installed by pacman, not pip) instead of wheels ?

10

musllinux has a wheel platform tag, but isn’t supported by the core team. More could be added.

11

This is already exactly what happens. You can use pacman to install Python and 1000 different Python packages including pip. Search for “python” here to see the list:

1 Like
12

This seems one of the few reasonable approaches, except for all packages are installed to the system global interpreter :grin:

13

Yeah, which reminds me: one of my regular work is to deal with container images, and for a while, official docker-hub python images were built on alpine linux (musl) but later they all migrated to debian (glibc). I think the reason is lack of first-class support of musl.

However, I think the arch of musl is promising. The code readability and modernity is better than glibc, in my opinion. I think in the future it will be one major arch of cpython.