Use Python 3.9 on Windows

[Starz0r]

Currently GitHub generates executables for Windows from Python 3.8, which has been EOL for more than 2 months now. This PR corrects it by building with Python 3.9 instead of an out of date Python.

[mikf]

The windows_x86.exe executables are meant for backwards compatibility. I'd like to keep them usable on Windows 7 machines, so (regular) Python 3.8 is the highest this can go.

[Starz0r]

I don't think it's worth supporting a version of Windows that old. Even so, the current (Windows) binaries on GitHub are built with CPython 3.8, and there isn't a distinguished x86 or x64 build. Just a singular x64 build that uses CPython 3.8. Is it possible that we can get binaries that are built with CPython 3.9 support?

[mikf]

The GitHub Actions workflow this PR is modifying is responsible for building and releasing "nightly" binaries at https://github.com/gdl-org/builds/releases

The stable releases from https://github.com/mikf/gallery-dl/releases are built on my own PC on a Windows 7 x86 VM and a Ubuntu 22.04 LTS VM as a part of running scripts/release.sh

[amayra]

is there any benefit of upgrading Python that is used for building if you don't use any new features in the newest versions?

[mikf]

CPython interpreters got faster / more efficient with each new version, especially Python 3.11. There are probably security related bug fixes that do not get ported to the EOL versions.

[Starz0r]

Is it possible to get a newer version of Python for future releases then?

[Hrxn]

Install a Python interpreter and simply run gallery-dl from the source code, problem solved.

[Starz0r]

@Hrxn So it's okay to keep releasing binaries using an outdated version of CPython, that'll eventually have vulnerabilities? Even if that doesn't matter to you, I think improving CPython performance is a good enough release to use newer non-EoL versions of Python.

[Starz0r]

@Hrxn By the way, having a person who's inquiring about this, and telling them to just run from source on their own installed version of Python is not "problem solved".

[mikf]

I do have a Windows 10 VM lying around, so I guess I could build EXEs there.

I'll probably rename the current Win7 Python 3.8 gallery-dl.exe builds to gallery-dl_x86.exe and use gallery-dl.exe for the new Win10 Python 3.13 builds, but this will have to wait till the next "major" release, i.e. 1.29.

run from source on their own installed version of Python is not "problem solved".

Why wouldn't it be "problem solved" for you in particular?
You want to use a different Python interpreter, so just do it yourself instead of relying on pre-built files provided by someone else.

Also, the builds from https://github.com/gdl-org/builds/releases use Python 3.13.

[Starz0r]

I do have a Windows 10 VM lying around, so I guess I could build EXEs there.

I'll probably rename the current Win7 Python 3.8 gallery-dl.exe builds to gallery-dl_x86.exe and use gallery-dl.exe for the new Win10 Python 3.13 builds, but this will have to wait till the next "major" release, i.e. 1.29.

Solid. Sounds good!

run from source on their own installed version of Python is not "problem solved".

Why wouldn't it be "problem solved" for you in particular? You want to use a different Python interpreter, so just do it yourself instead of relying on pre-built files provided by someone else.

It's not that I want to use a different interpreter, it's just the fact that the interpreter is outdated and no longer supported, yet it's still being distributed to downstream users. Sure, I could build it myself, or just run from source, but that's not really the point.

Also, I literally maintain the Chocolatey package for gallery-dl. Inquiring into why binaries I'm packaging are using an old interpreter isn't that far of a stretch?

Also, the builds from gdl-org/builds/releases use Python 3.13.

Didn't know nightly releases existed, but might consider packaging these to users as well.