Set up delvewheel as the default repair wheel command for Windows

[agriyakhetarpal]

This PR adds delvewheel in the usual places for it to the default wheel repair command for our Windows platform in cibuildwheel v4. The current version is v1.12.0, and the project has become fairly stable as of 2026.

I think I covered everything, but please LMK if I missed anything. @joerick, since you expressed interest in adding this in various issues, it'd be great if you could take a look – and by all means, please feel free to push any further changes to my PR!

Also, cc: @adang1345 (I hope it is okay for us to ping you here!)

Thank you! :)

• Closes delvewheel as default for windows repair command #2803
• xref Plan for cibuildwheel 4.0 #2828
• xref Repairing Windows wheels #459, Repairing Windows wheels #459 (comment)
• delvewheel was first suggested in cibuildwheel shoutout on Python Bytes podcast #620 and it's finally happening!
• see also Windows wheels depending on libgcc_s_seh-1.dll and libstdc++-6.dll, why? How to use clang-cl? #1798

Also, perhaps we should look at #1567 too while we're at it, based on the open issues that reference "delvewheel".

[agriyakhetarpal]

One of the concerns we had was listed in #2047 (comment), about users having to add --add-path to the Windows wheel repair. I think that can be resolved if we make a note of this in the docs, but I will wait for preliminary review suggestions to come, first.

[nilsnolde]

Thanks, I appreciate that:) I'll just reiterate that IMO this is a more general Windows limitation, they don't have a proper system package manager (EDIT: though I did see a winget randomly recently) and the way I always use it is to reference vcpkg/conan dll's (there's probably more scenarios for sure, but this might be the most dominant). Adding it to the docs will be appreciated by everyone. Much better than the current situation:)

[agriyakhetarpal]

Thanks, I appreciate that:) I'll just reiterate that IMO this is a more general Windows limitation, they don't have a proper system package manager (EDIT: though I did see a winget randomly recently) and the way I always use it is to reference vcpkg/conan dll's (there's probably more scenarios for sure, but this might be the most dominant). Adding it to the docs will be appreciated by everyone. Much better than the current situation:)

Good point, thanks @nilsnolde. I agree that vcpkg is the closest to this kind of thing out there (and even Meson wraps is one more option). I added a note in 8cfdbf7. Does that suffice? :)

[nilsnolde]

I added a note in 8cfdbf7. Does that suffice? :)

@agriyakhetarpal IMO sounds perfect, thanks!

[adang1345]

By the way, I just made a new delvewheel release 1.12.1, which automatically excludes the DLLs provided by or required by GraalPy (vcruntime140.dll, vcruntime140_1.dll, and python-native.dll).

[agriyakhetarpal]

Awesome, thanks a lot @adang1345!

[joerick]

Thanks for working on this agriya!

Looks good from my end overall.

[joerick]

While I'm thinking about it, this is a change that needs a good notice in release notes. Things to mention in the release notes

• delvewheel runs by default , it will try to find and bundle dlls into your wheel
• you can configure using repair-wheel-command, or
• disable it (returning to pre-4.0 behaviour) by setting repair-wheel-command to empty-string.

I think the crucial thing to mention in release notes will be how to disable it for upgrading users that don't want this change yet.

[agriyakhetarpal]

FYI, I partially reverted the constraints bumps in 17d38ba because there was a failure likely due to pip==26.1.1 in https://github.com/pypa/cibuildwheel/actions/runs/25509576233/job/74864644182?pr=2831, which I was kind of stumped by, where GraalPy's pip was unable to install delvewheel at all. cc: @timfel for visibility. pip==26.0.1 works fine.