bump cibuildwheel action to v2.17.0

[arvidn]

No description provided.

[xavier2k6]

@arvidn try using Boost 1.82.0 instead.

[arvidn]

it looks like there's some progress. Now the failure is a rename that happens after the build, here.

rename build\lib.win-amd64-cpython-37\libtorrent.cp37-win_amd64.pyd -> build\lib.win-amd64-cpython-37\libtorrent\__init__.cp37-win_amd64.pyd
error: [WinError 2] The system cannot find the file specified: 'build\\lib.win-amd64-cpython-37\\libtorrent.cp37-win_amd64.pyd' -> 'build\\lib.win-amd64-cpython-37\\libtorrent\\__init__.cp37-win_amd64.pyd'

[xavier2k6]

It should make no difference to error but just as an FYI v2.18.0 of cibuildwheel action has been released.

[qstokkink]

Thanks for picking this up! I'd like to see this fixed, so I'll support to the best of my ability.

[Click me for analysis]

If I'm interpreting the log correctly, this is the "rename" log entry just before failure:

libtorrent/bindings/python/setup.py

Line 361 in 31003b7

log.info("rename %s -> %s", src, dst)

I assume the following os.rename(src, dst) is the cause of the crash.

On the other builds this succeeds. For example, Mac:

common.copy /Users/runner/work/libtorrent/libtorrent/bindings/python/build/lib.macosx-10.9-x86_64-cpython-37/libtorrent.cpython-37m-darwin.so
    ...updated 276 targets...
    rename build/lib.macosx-10.9-x86_64-cpython-37/libtorrent.cpython-37m-darwin.so -> build/lib.macosx-10.9-x86_64-cpython-37/libtorrent/__init__.cpython-37m-darwin.so

However, on Windows, build\lib.win-amd64-cpython-37\libtorrent.pyd is apparently created instead of the expected build\lib.win-amd64-cpython-37\libtorrent.cp37-win_amd64.pyd:

common.copy D:\a\libtorrent\libtorrent\bindings\python\build\lib.win-amd64-cpython-37\libtorrent.pyd
    bin\msvc-14.3\rls\adrs-mdl-64\cxstd-14-iso\pythn-3.7\libtorrent.pyd
            1 file(s) copied.
    ...updated 266 targets...
    rename build\lib.win-amd64-cpython-37\libtorrent.cp37-win_amd64.pyd -> build\lib.win-amd64-cpython-37\libtorrent\__init__.cp37-win_amd64.pyd

As I see it, you could remedy this by either changing the setup.py output-detection logic or the build logic that creates the output in the first place (probably in the jamfile).

[qstokkink]

@arvidn if you want some help and you don't mind me hammering your GitHub Actions builds for a bit, I can try getting the action (back) up and running. Just let me know and I'll pick this up.