Evaluate upgrading python version to 3.12

[cpeel]

GG2 is currently being developed against python 3.10 per the README.md and it is currently supported for security releases. 👍. However, binaries aren't available for the most recent 3.10 release on Windows. python 3.12 is the most recent supported version -- see the python version status.

We should consider updating the minimum version to 3.12 so we're developing against the latest version. Windows and macOS (via Homebrew) have ready access to python 3.12.

The biggest downside and thing to consider is for Linux users. Some very common, supported platforms include older versions:

• Ubuntu 20 (in support through mid 2024) uses python 3.8
• Ubuntu 22 uses python 3.10

Getting newer versions installed on those platforms is doable but often not trivial. We should consult with some of our GG1 Linux users and get their thoughts on python version and either proceed with this work or WONTFIX this issue and punt it to the future.

I don't see us targeting new python features that would preclude users from running on older versions, but for support purposes by having a target version we test and validate against is useful -- and that may be sticking with 3.10.

[srjfoo]

Bearing in mind that I don't know anything about what works best for various flavors of Linux, homebrew (package manager for macOS) is also available for Linux. Would that be a possibility, or are there too many problems associated with it (starting with the fact that most Linux users may be reluctant to install yet another package manager)?

[tangledhelix]

There are other potential solutions than Homebrew:

• pyenv
• Nix
• Plain old download from python.org
• Docker
• We can bundle a pre-configured Python & library catalog with the delivered Guiguts install

IMHO for development purposes, pyenv would be a great choice.

For the final deliverable, I lean toward bundling a Python so it's easier to control the dependencies. Particularly on macOS, where that's a common model for apps.

[windymilla]

I need to look back at what went wrong for me when I started GG2 and installed 3.12. It was quite possibly just my inexperience with Python and/or a previously installed older version that caused me problems, which I eventually resolved by installing 3.10.
The other thing at the back of my mind is that it might have been something to do with PIL/Pillow?

[tangledhelix]

I agree with @srjfoo about consulting or surveying the Linux users.

That aside, let me put on a couple of my hats and say some more about it.

"Python Developer" hat

I would suggest these factors to consider:

How long the Python version will be supported

You can determine this from the Python downloads page. Given the information available there today, 3.12 is a reasonable choice for this project IMO, even though it is the newest major release.

• This project is still under development, by the time it's released generally, 3.12 will have much more age on it
• 3.12.x release scheduled (in PEP 693) suggests 3.12 will get bugfixes through about the end of 2024
• Whereas 3.11.x (PEP 664) will get security-only changes starting April 1, 2024; a less desirable state

Features in the Python release

As we move forward with the project, we'll eventually come to another decision point, when should we require 3.13? 3.14? And so on.

Here I think there are really only 2 factors.

First, the support question (see above).

Second is features we want to take advantage of. A good example of this is "f-strings" introduced in Python 3.6, which caused a lot of projects to make that jump. Future Pythons may have some similarly attractive feature or change.

A note on having multiple Pythons installed on a system

An easy way to manage specific (and multiple) Python versions is pyenv for Mac/Linux, or pyenv-win on Windows. It's not the best way to do things in production IMO (though I have seen it used for production) but for development, or for end-user use-cases such as Guiguts, it can definitely work.

"Linux administrator" hat

Distro lag

Linux distributions always, always lag the state of the art. You will always be on an "old" Python if you use the one provided by the system. How old depends on the vendor (RHEL is way "older" than Ubuntu, etc).

This should, IMHO, be a question to Linux users about hassle factor. Maybe they will collectively say that using pyenv to get a different Python is a-ok with them. Maybe not.

Also, specific to Debian & Ubuntu (afaik) one could use a PPA like deadsnakes to get a pre-packaged Python via the normal tool (apt, in this case) without having to build it yourself. This is a very viable option; I use deadsnakes at work to get a newer Python than I otherwise could use, for multiple mission-critical use cases. I'd be comfortable suggesting people should use it.

Packaging

Ideally we can provide easy packages for users to install, on any platform. I have various scripts that work toward making .app bundles on macOS. There are installers for Windows, of course. And we could target certain Linux distros as well, perhaps producing .deb packages for Ubuntu users. (Which formats matter depends on what distros people are using, I suppose...)

In any of these cases, we could choose to bundle Python with the application on one or all of the platforms, if it makes sense. That had been my plan (er, with Perl) for the macOS packaging effort. It would entail more work to figure out how to do it, and depending on the details, maybe commitments from some people to manage packaging. In the case of macOS to do it "right" you need an Apple Developer signing certificate etc. I already volunteered to work on that in #29, but packaging for Windows, Ubuntu, etc would probably be more for others. (I could try it on Ubuntu as well, but I'm a server person, I don't have any Ubuntu desktops around and my experience there is limited.)

[windymilla]

As mentioned in the Slack dev channel, I have used pyenv(-win) to manage Python versions with little trouble. Since pyenv is originally a Linux/Mac tool, hopefully devs on those platforms would be able to use it. This has the advantage of being able to easily switch between Python versions for testing, but maybe more importantly, isolating you from the "system-installed" (or Homebrew-installed?) version.

[srjfoo]

Even if what I mostly do is testing, I should probably be able to do the same if we're going to be doing testing on multiple versions of python. I will need instructions on setting up pyenv on my Macs (currently I've got v10 on the M1 and v12 on the Intel, but it would be better not to have to switch between machines).

[cpeel]

Sharon, it doesn't matter how one gets the version of python needed on their system. If homebrew works for you, no reason to switch to pyenv.

[cpeel]

This is great information, thank you for that detailed write-up @tangledhelix!

Given the above, my proposal is that we target Python 3.11. That version:

• is still getting bug fixes & supported through the end of 2027
• available via pyenv, python.org, homebrew, and deadsnakes (for Ubuntu 20.04 and 22.04)
• is the version that is coming in Ubuntu 24.04 LTS (and I suspect is in Debian bookworm but packages.debian.org is 503ing for me right now)

That seems like the most reasonable middle ground of being fully recent and still giving a nod to popular LTS Linux distributions (current and future).

[tangledhelix]

One minor nit with what @cpeel wrote: Python 3.11 doesn't get bug fixes through end of 2027, that's the end of security fixes. The schedule is defined in PEP 664. Excerpts:

3.11.0 final: Monday, 2022-10-24 (actual)

Final regular bugfix release with binary installers:
3.11.9: Monday, 2024-04-01 (projected)

3.11 will receive bugfix updates approximately every 2 months for approximately 18 months. Some time after the release of 3.12.0 final, the ninth and final 3.11 bugfix update will be released. After that, it is expected that security updates (source only) will be released until 5 years after the release of 3.11.0 final, so until approximately October 2027.

All that said, I think 3.11 is probably the right version, for the reasons you wrote. I just wanted to make sure everyone is working with the right terminology & dates.

[cpeel]

Thanks for that correction @tangledhelix!

[windymilla]

Sorting a PR to upgrade to 3.11, as per above discussion