Evaluate upgrading python version to 3.12 about guiguts-py HOT 11 CLOSED

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)?

from guiguts-py.

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.

from guiguts-py.

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?

from guiguts-py.

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.)

from guiguts-py.

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.

from guiguts-py.

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).

from guiguts-py.

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.

from guiguts-py.

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).

from guiguts-py.

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.

from guiguts-py.

Thanks for that correction @tangledhelix!

from guiguts-py.

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

from guiguts-py.