[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!

[agriyakhetarpal]

Let's see if this works!

[agriyakhetarpal]

Something is pulling in 26.1.1 from a venv somewhere, but I can't yet figure out what. It's stopping the tests from proceeding, then moving on to the tests we actually want to see run (the C extension with an unfindable DLL).

[joerick]

Brilliant, that's perfect.

[joerick]

There's no equivalent test for auditwheel or delocate, so consistency called for doing so, but I think it's probably alright to bring it back

I'd reckon our integration tests do cover auditwheel, because the 'manylinux' filename is set by that tool. Not checking delocate on macOS is maybe an opportunity for better test coverage :)