[Bot] Update dependencies

[cibuildwheel-bot]

Update the versions of our dependencies.

PR generated by "Update dependencies" workflow.

[mayeut]

I find weird that tests are passing on macOS given the minimum macOS deployment target for Python 3.12 has changed: https://www.python.org/downloads/release/python-3126/
(not that weird on Azure / GHA given we use the pre-installed 3.12.5).

Here's the output I get for Python 3.12.6 on my laptop (& 3.11 just to check there are no overrides in the environment):

% python3.12 -V
Python 3.12.6
% python3.12 -c 'import sysconfig; print(sysconfig.get_platform())'
macosx-10.13-universal2
% python3.11 -c 'import sysconfig; print(sysconfig.get_platform())'
macosx-10.9-universal2

[henryiii]

The min version for macOS jumped to 10.13 for Python 3.12. We’ll need to decide how to handle that.

Edit: already addressed, though are we sure this is what we want to do? The only other choice would be to not upgrade Python 3.12.

[mayeut]

though are we sure this is what we want to do?

IMHO, while I would have preferred not to change the default deployment target for Python 3.12 now, I think it's the best way forward and has probably very little impact for the following reasons:

• macOS 10.12 has been EOL for almost 5 years: https://endoflife.date/macos
• The stats for macOS <=10.12 show very little usage (less than 0.03% for pip itself): [24.2] installs fail on macOS 10.12 and older due to bundled truststore issue pip#12901 (comment)
• keeping Python 3.12.5 is not as simple as not upgrading. It would require forcing a downgrade (in CI only) if an official Python 3.12 >= 3.12.6 is installed which will be the case at least in GHA / Azure in the coming weeks. The downgrade will most likely fail if the same official version is used to run cibuildwheel itself thus requiring everyone to change their workflows to force install Python <= 3.12.5 before running cibuildwheel.

[joerick]

Changing the minimum is unfortunate, but seems okay to me too.

• The stats for macOS <=10.12 show very little usage (less than 0.03% for pip itself): [24.2] installs fail on macOS 10.12 and older due to bundled truststore issue pip#12901 (comment)

This agrees with my analysis, for what it's worth :)

[henryiii]

IMO, we might want to make this a minor release instead of a patch one for this. (Maybe other things, too, but this seems minor-release worthy, as it will produce different wheels)

[joerick]

This also gives us 3.13.0rc2.

[EwoutH]

I would love a new cibuildwheel release with Python 3.13.0rc2.

[joerick]

I hear you, we're bumping minor so I want to get #1961 in as well, that may well be ready though, I just need to find a few minutes to review it

[henryiii]

What's the timeline on #2002, @agriyakhetarpal? Is that something we'd also like?

[henryiii]

I would love a new cibuildwheel release with Python 3.13.0rc2.

Anything important in rc2, @EwoutH?

[agriyakhetarpal]

What's the timeline on #2002, @agriyakhetarpal? Is that something we'd also like?

We expect to release Pyodide by the end of September (pyodide/pyodide#5064), so it would be great if #2002 could make it to a cibuildwheel release around that time. It's probably not urgent, so it would be nice to get it in a further version, say, v2.22.0, after v2.21.0 gets released here (I would have suggested v2.21.1, but that would break SemVer by incorporating a feature in a patch release).

[henryiii]

We are off by one for SerVer, as long as it doesn't break anything existing, the third digit is probably fine. Minor releases can make breaking changes since removing or adding wheels is breaking.

[henryiii]

Okay, so these two PRs are ready to merge, I think? (#1961)

[agriyakhetarpal]

We are off by one for SerVer, as long as it doesn't break anything existing, the third digit is probably fine. Minor releases can make breaking changes since removing or adding wheels is breaking.

Sounds great, thanks for the context! #2002 won't block this release, then, and a subsequent patch release with it would be nice. I will get the necessary changes implemented upstream, first.