deprecation: cp313t

[mayeut]

Free-Threading Python 3.13 was experimental.
Now that Python 3.14 has been released with explicit support, we can schedule removal of Python 3.13 free-threading.

towards #2683
see also #2684

[henryiii]

As soon as we are sure the next version is a minor version bump, I think this should go in.

[mayeut]

I rebased to fix the conflict with typing.Self. I had to add an exception for mypy checks.

As soon as we are sure the next version is a minor version bump, I think this should go in.

The removal is now approximately 1 month away.
Should we merge and bump to a minor for the next release in any case ?
Should we just add a deprecation notice in release notes of the next version if it's a patch version ?

I'm leaning towards the first option for cp313t.
The second option could be used to raise awareness for Python 3.8 removal and for which we probably don't want to show a warning for users that will be stuck producing Python 3.8 wheels for a while with the last version of cibuildwheel able to produce cp38 wheels.

[henryiii]

If I get a chance to work on multi-wheel output (I might in 1-2 weeks), that would be a good feature for a new minor version.

[joerick]

Given the only functionality change here is the removal of cpython-freethreading from enable = "all", I'd be okay with pushing this out on a patch release. If we're only a month away from removing it entirely, and that variant has always been 'experimental', seems okay to me.

[mayeut]

I rebased / forced push with fixes to tests in order to get proper typing in there.

[rgommers]

Hi, this seems perfectly fine in principle, however the timeline here seems very rushed. There are a lot of projects using this in both regular CI and in release scripts. Even when cibuildwheel itself is pinned, build dependencies (e.g., numpy) typically aren't. So removing cp313t builds out of order in an unplanned fashion is going to lead to some confusion and breakage.

An announcement on DPO and a slightly longer timeline so removals from CI across O(100) projects can be done systematically would be helpful.

I now realize that gh-2683 has been open for several months, but that had next to no visibility. If I didn't know about it (working on both Python packaging and free-threading), then I'm pretty sure that the vast majority of package authors that use this feature won't know yet.

[henryiii]

We are starting with a deprecation warning, which should increase visibility.

[rgommers]

Yes, that just appeared. My comment is about the timeline for removal - manylinux set this at 5 May, and from this discussion it sounds like cibuildwheel will follow shortly after. That's about one month from announcement to full removal - very short. This is the bottom of the stack. I'm happy for my team to do a lot of the cleanup work, but 1 month (especially coinciding with CPython 3.15.0 beta1 which will have priority) is not ideal.

[henryiii]

You can keep the old cibuildwheel, which will be pinned to an old manylinux, which will still have it. Though then you can't do beta one.

I think this would be doable for NumPy; the dev branch could drop 3.13t and add the beta, but it wouldn't release till rc1, which is much further away, and probably fine for 3.13t? Remember that was always experimental, unlike 3.14t.

I could see an argument that keeping it around a bit longer so that it doesn't collide with the addition of 3.15 - but I don't make decisions in manylinux. ;)

[joerick]

@rgommers thanks for chiming in. Sorry for causing a headache.

Even when cibuildwheel itself is pinned, build dependencies (e.g., numpy) typically aren't. So removing cp313t builds out of order in an unplanned fashion is going to lead to some confusion and breakage.

Just so that I understand, you'd rather that numpy dropped 313t before cibuildwheel? Or you'd rather that projects downstream of numpy had a chance to drop 313t before numpy is forced to?

[rgommers]

Or you'd rather that projects downstream of numpy had a chance to drop 313t before numpy is forced to?

Yes, this. It's best to go in reverse order through the whole dependency tree, to avoid getting builds from source (which will then likely fail). And sometimes PRs take a while before getting merged, some maintainers have questions, etc. We'll have to go through a good part of what's tracked at https://py-free-threading.github.io/tracking/.

CI failures aren't the end of the world, but we spent a lot of time asking maintainers to pretty please accept adding cp313t wheels, so I'd rather minimize any friction to not burn any goodwill.