Skip to content

Conversation

@clin1234
Copy link
Contributor

Also skip building cffi backend for 3.13t

Copy link
Owner

@indygreg indygreg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. I'm going to merge this. But with just the cffi version bits: I want to defer standing up CI coverage of free-threaded Python to its own PR.

@clin1234 clin1234 marked this pull request as ready for review August 24, 2025 20:55
indygreg pushed a commit that referenced this pull request Aug 24, 2025
We need cffi 2.0 for nogil support. cffi 2.0 only implements nogil
support on 3.14+, so we need to disable cffi for nogil on 3.13.

Closes #274.
indygreg pushed a commit that referenced this pull request Aug 24, 2025
We need cffi 2.0 for nogil support. cffi 2.0 only implements nogil
support on 3.14+, so we need to disable cffi for nogil on 3.13.

Closes #274.
indygreg pushed a commit that referenced this pull request Aug 24, 2025
We need cffi 2.0 for nogil support. cffi 2.0 only implements nogil
support on 3.14+, so we need to disable cffi for nogil on 3.13.

Closes #274.
indygreg pushed a commit that referenced this pull request Aug 24, 2025
We need cffi 2.0 for nogil support. cffi 2.0 only implements nogil
support on 3.14+, so we need to disable cffi for nogil on 3.13.

Closes #274.
@indygreg indygreg closed this in 68e4389 Aug 24, 2025
@reneleonhardt
Copy link

Is this correct, cffi 2.0 is unusable on normal Python 3.13 (non-free-threaded)?

"cffi~=1.17; platform_python_implementation != 'PyPy' and python_version < '3.14'",

This forces pip to downgrade to cffi 1.17 even if normal non-free-threaded wheels exist like cffi-2.0.0-cp313-cp313-xxx.whl

https://pypi.org/project/cffi/2.0.0/#files

Please note that cffi doesn't build free-threaded wheels for Python 3.13 (cp313t), I don't know why.
They build those only for Python 3.14 cffi-2.0.0-cp314-cp314t-xxx.whl

Unrelated:
Why is it necessary to close pull requests with unmerged commits, only to merge the contents nevertheless?
This looks very confusing in the GitHub UI, no pull requests have been merged since February, including this one:
https://github.com/indygreg/python-zstandard/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Amerged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants