-
Notifications
You must be signed in to change notification settings - Fork 0
Add Python 3.13 to the test matrix #35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #35 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 2 2
Lines 7 7
=========================================
Hits 7 7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Do we want to also add free-threaded Python to the CI? I believe this 3.13 will by with GIL. E.g. https://github.com/deadsnakes/action seems to be a way that we can already enable GILless right now |
|
Aaand it's delayed by a week: https://blog.python.org/2024/10/python-3130-release-candidate-3-released.html |
They also say
So would be fine with me if we add the prerelease to matrix. Maybe we should have 'the next prerelease' in a test anyway so we don't have to suddenly solve bugs. But well it is also okay to stay behind. |
|
Meh, Windoof no worky 🙄 |
|
Hmm, now 3.13 is finally out (and supported by the action) and yet it's still failing on Windows. Not sure what's going on... |
|
Bumping numpy seems to have finally solved this. However, I will wait with the merge, because right now this would crash all our packages that are limited to 3.10-3.12. Needs to be done carefully and at once. But at least no we can do it... |
hugobuddel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good! Kinda the point of DevOps is that we don't have to make changes to each individual repository to test each new Python release, but that kinda went out of the window. I understand why, but not sure what the best solution is
|
To square the circle of including the new Python versions here first, which would make the workflows fail in all projects that don't support that yet, but also be able to test adding the new Python version in those (which relies on that version being included here), I suggest following this: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#example-preventing-a-specific-failing-matrix-job-from-failing-a-workflow-run The example shown there is pretty much exactly what we'd need here, i.e. set all the Python 3.13 versions to "experimental", allowing them to fail until we think we caught up with all the packages, then we can remove this again (I'll simultaneously create an issue for that, otherwise we forget, I know us 🙃). If we missed any packages, we'll see it then. |
|
That is a nice feature |
|
Alright, I ended up putting a "
In the interest of progress, I take this as approval. Indeed the PR was approved before I added this now, so I'll merge it. |
This fails waaay to often. Need to find a permanent solution.

The Python version corresponding to Donald Duck's license plate will drop tomorrow 🚀