Skip to content
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

python3.13 support + docker #1453

Open
imkebe opened this issue Oct 9, 2024 · 7 comments
Open

python3.13 support + docker #1453

imkebe opened this issue Oct 9, 2024 · 7 comments
Assignees

Comments

@imkebe
Copy link

imkebe commented Oct 9, 2024

Python 3.13 had been released. There is no build for such version of the docker images

@callahad
Copy link
Collaborator

@thresheek Would it be possible for SysEng to bump our Python language versions without a Unit release, or would that be a bit of a pain? 🙏

@thresheek thresheek self-assigned this Oct 15, 2024
@thresheek
Copy link
Member

I think we can do the following:

  • Bump Python version to 3.13+3.12 in the master branch
  • Backport those commits to the packaging branch
  • Do a new PR to Docker Library to pick up those changes.

A couple of things that are potentially breaking someone's workflows, as we typically publish two latest language runtime versions:

  • we'd drop 3.11 from the library definition (published images like unit:1.33.0-python3.11 and unit:python3.11 will stay as is, albeit not easily discoverable)
  • we'd move unit:python3 and unit:python tags to 3.13 instead of a current 3.12

@imkebe
Copy link
Author

imkebe commented Oct 15, 2024

One thing to consider in general 3.13 release. Default Python 3.13 has similar behaviour like 3.12 however there is new 3.13t version that has changes to GIL (threading mechanism). If this version would be supported by Unit it should be tested. However it's considered as an experimental feature.

@callahad
Copy link
Collaborator

@thresheek Would it be possible to avoid the potential of breakage by instead:

  • Keeping 3.11 on the packaging branch (so Docker Library publishes 3.11, 3.12, and 3.13)
  • Keeping unit:python at its current 3.12, so it only revs when we do our next full Unit release?

@imkebe I'm super excited about the GIL removal, but we'll probably not post images to Docker Hub while it's still experimental. I do encourage you to try it locally, though, and report back!

@imkebe
Copy link
Author

imkebe commented Oct 22, 2024

@callahad That is what I wanted to say - GIL is a experimental build so don't bother to include it in a Unit supported at the moment. That will come with python 3.14

@thresheek
Copy link
Member

The current implementation of the "library" definition sorts the versions and assigns non-versioned variants to whatever the latest is.

We can cheat a bit and provide the manually edited file, of course, however it's not very nice from etical POV since we also publish "this file is generated via ..." line in there...

@callahad
Copy link
Collaborator

Fair enough. I'm fine with splitting the difference: publish 3.11, 3.12, and 3.13; and allow unit:python to point to 3.13.

If you're implicitly pointing at the latest version of Python, you get the latest version of Python.

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

No branches or pull requests

3 participants