Update Python to 3.13.0 and add support to Windows on AMD64. #1477
Conversation
juj
force-pushed
the
update_python_to_3.13.0
branch
from
4662f05
to
eacc02c
Compare
…packaging of pywin32 because it is no longer shipped via separate binary installers, but has migrated to use pip.
| @@ -32,29 +32,35 @@ | |||
| from subprocess import check_call | |||
| from zip import unzip_cmd, zip_cmd | |||
|
|
|||
| version = '3.9.2' | |||
| version = '3.13.0' | |||
There was a problem hiding this comment.
Do we need to upgrade to such a recent version? i.e. what as the first version of which arm64 packages are available.
The slight downside of using a bleeding edge version of python like this is that we accidentally start depending of very new python features that folks on older/stable versions might not have.
There was a problem hiding this comment.
I was pondering about this too. My thinking here is that since we do these updates so rarely, maybe we would for once update to a modern version.
Python 3.9, 3.10 and 3.11 will no longer receive bugfixes to any issues one might run into. I don't think it makes sense to update to any of these versions, even if one of these would be the earliest ones to support Windows on ARM64.
Python 3.14 is in feature development. So we definitely will not want to update to that branch.
Python 3.12 and Python 3.13 have finished feature development and are actively receiving bufixes. It feels that either of these would be the ones to focus on.
I.e.
I picked 3.13 since it is newer, and I could not find any mentions of OS support cutoff differences between 3.12 and 3.13.
we accidentally start depending of very new python features that folks on older/stable versions might not have.
3.13 is stable. (or rather, actually, every python version is broken in different ways. But Emscripten test suite is fortunately evolved to be good at finding ways that Python works or doesn't work out)
We do bundle python for the very purpose to normalize which version we provide to people? So this covers Windows and macOS users. On Linuxes where this currently is not the case, I understand updating to a newer version should be possible easier with their package managers?
There was a problem hiding this comment.
I suppose the other alternative could be 3.12.7 . At the end of the day I don't feel that strongly, but generally would strive to standardize to latest version, especially if Emscripten test suite will pass with 3.13.0. (Testing that out on Windows, although I am seeing Windows failures already before this update, making it a bit more time consuming to compare)
juj
force-pushed
the
update_python_to_3.13.0
branch
from
eacc02c
to
eea63b9
Compare
|
I guess to perform that actual upload I should download this PR and run the update script? |
| @@ -65,7 +65,7 @@ https://emscripten.org/docs/building_from_source/toolchain_what_is_needed.html. | |||
|
|
|||
| ### Linux | |||
|
|
|||
| - `python`: Version 3.9.2 or above. | |||
| - `python`: Version 3.13.0 or above. | |||
There was a problem hiding this comment.
I'm not sure we want to drop support for python 3.9 just because emsdk bundles a bleeding edge version. I think the idea is that we still want to support the system version of python on older/stable linux releases.
| @@ -10,15 +10,19 @@ | |||
| We only supply binaries for windows and macOS, but we do it very different ways for those two OSes. | |||
There was a problem hiding this comment.
Perhaps add another sentence here: "On linux, we simply depend on the system version of python".
Update Python to 3.13.0 and add support to Windows on AMD64. Rewrite packaging of pywin32 because it is no longer shipped via separate binary installers, but has migrated to use pip.