build/pkgs/python3: Update to 3.12.4; declare support of Python 3.12.x stable

[mkoeppe]

https://docs.python.org/3/whatsnew/changelog.html#python-3-12-4-final

• In part cherry-picked from Python 3.12.x #36181

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

• Depends on build/pkgs/python3: Update to 3.11.8, remove Cygwin patches, remove pointless rpaths on macOS #37914 (merged here)
• Depends on declare the last arg to GAP_CallFunc3Args volatile #37951 (merged here for Segfault testing src/sage/libs/gap/element.pyx on python 3.12 #37026)
• Depends on CI: Fix handling of deletions/renames; Build&Test: Uninstall/build changed packages; Linux Incremental: Update platforms #38144 (merged here for testing)

[github-actions]

Documentation preview for this PR (built with commit 2d9dba3; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[tornaria]

LGTM but I have not tested and there are failing CI here.

BTW, it seems to me that there is no value on having 7 separate commits here. Besides, the first commits seem they would be broken as updating python without removing the patches possibly leads to the patches not applying cleanly.

In any case, this looks like a simple way to update python in sage-the-distro, so thanks.

FTR, I've been shipping sagemath with python 3.12 without problems since October.

[mkoeppe]

Some of the commits are cherry-picked from elsewhere. Not squashing it makes it easier for me to track what has been merged.

[mkoeppe]

The "CI Linux Incremental" runs include some failures from unrelated problems. I'll look at it carefully in the next days. I have also run the full portability tests from a branch that has merged a number of other upgrade PRs, I'll inspect it as well. That's https://github.com/mkoeppe/sage/actions/runs/8761823524

[tornaria]

Some of the commits are cherry-picked from elsewhere. Not squashing it makes it easier for me to track what has been merged.

I understand, but as a general rule, isn't it better to squash in working units (e.g. update version + adjust patches) so each commit is "correct"? OTOH, I understand the way sagemath works the "minimal unit of work" is a PR as merged by Volker.

For your problem, I think if you reorder and/or squash some commits, and later rebase your other branch on top of this one, it should do "the right thing". I do it all the time since we have rules about this on the void-packages repo (merges are not allowed and several commits to the same package have to be squashed together, so we edit the history a lot). If you want to make sure, you can rebase your other branch before squashing (or you squash on your other branch and then cherry-pick again).

EDIT: added a missing question mark in my first sentence above.

---

About the PR itself, I looked casually at the CI and you seem to be right. If you trust the CI, feel free to bump this. You have much better feeling for the CI, so I trust you on this.

[mkoeppe]

as a general rule, isn't it better to squash in working units (e.g. update version + adjust patches) so each commit is "correct"?

No, neither is there such a general rule, nor do we have such a policy as a project.

I'd say it's best to leave it to experienced users of version control systems to do what works best for them.

I understand the way sagemath works the "minimal unit of work" is a PR as merged by Volker.

Exactly.

[tornaria]

as a general rule, isn't it better to squash in working units (e.g. update version + adjust patches) so each commit is "correct"?

No, neither is there such a general rule, nor do we have such a policy as a project.

We should strive to have a nice clean history that is useful in the future. Do you use git blame regularly? IME the history of sagemath is not very easy to work with, and some easy rules as above would go a long way, together with a judicious use of rebase and squash, and less reliance on merges (especially the ones done on the gh web interface).

I'd say it's best to leave it to experienced users of version control systems to do what works best for them.

No, because sagemath is not a single person project. This is similar to code style: we can have different ideas on what works best for an individual, but for collaboration is best to have some common ground.

I understand the way sagemath works the "minimal unit of work" is a PR as merged by Volker.

Exactly.

And --first-parent (which I learnt from you) is very useful, but unfortunately it doesn't work with git blame so having a better history in each PR is still useful. Also, there is a problem when PRs have "dependencies" that are merged in, because they will sometimes show as a single merge.

[mkoeppe]

On Sun, Apr 21, 2024 at 4:23 PM Gonzalo Tornaría ***@***.***> wrote: as a general rule, isn't it better to squash in working units (e.g. update version + adjust patches) so each commit is "correct"? No, neither is there such a general rule, nor do we have such a policy as a project. We should strive to have a nice clean history that is useful in the future.

I don't see this as a priority for the project at all. I do sometimes also ask junior developers to clean up an overly messy commit history; and I also have taken maintainer action doing the same in rare cases. But there is a balance between cleanliness and being welcoming to a wide range of developers. Note that our project is already pretty heavy-handed with its rather extreme documentation requirements, plus the friction from a review process and merge process that both seem to take place on a galactic timescale. Adding on top of that extra requirements regarding the commit history could be too much.

[mkoeppe]

And --first-parent (which I learnt from you) is very useful, but unfortunately it doesn't work with git blame

Maybe you're looking for git annotate --first-parent?

[tornaria]

And --first-parent (which I learnt from you) is very useful, but unfortunately it doesn't work with git blame

Maybe you're looking for git annotate --first-parent?

Yes, thanks! It does work with git blame as well.

[mkoeppe]

Tests at https://github.com/mkoeppe/sage/actions/runs/9277177490, https://github.com/mkoeppe/sage/actions/runs/9277177488

[mkoeppe]

Tests at https://github.com/mkoeppe/sage/actions/runs/9439361581