Python version update

[MNiedzielski]

Enable tests for current Python versions.

[kvid]

I'm sorry this PR hasn't got any attention since @MNiedzielski marked it ready for review several months ago. Please compare these suggested workflows and setup changes against some similar changes included in PR #251 (that also contains a huge amount of other changes). They are not equal, and I wonder if anyone can describe some advantages and disadvantages between the different choices.

• It seems this PR suggests supporting Python 3.7, 3.8, 3.9, 3.10, and 3.11 - and test all of them in the workflow.
• It seems PR Large scale refactoring #251 suggests supporting Python 3.8, 3.9, and 3.10; but only test 3.8 and 3.10 in the workflow.
• It seems reasonable to exclude 3.7 as it reached end-of-life earlier this summer.
• Why are some version numbers quoted, but not all of them in the workflows file?

[amotl]

Hi there,

first of all, thank you for your contribution, Mark. As @kvid outlined, GH-251 will bring in a few modernizations in this regard already. I think we should merge that one first, and then see what's left.

Which Python versions should we support? Why include these? Why exclude the others?

https://devguide.python.org/versions/ has a good orientation what to support in general. When there are other obstacles, regarding dependencies or such, with corresponding reasons to drop support for older Python versions earlier, before their official EOL date, so be it.

Why are some version numbers quoted, but not all of them in the workflows file?

Version numbers like 3.10 will be interpreted as "3.1" when not being quoted, which is wrong.

With kind regards,
Andreas.

[MNiedzielski]

@kvid @amotl No strong preferences here. Agreed 3.7 should be dropped. Perhaps even 3.8 be dropped and 3.12 added to further future-proof. Also agreed GH-251 should merge first, as it ought to reduce any fixes triggered by enabling tests for newer versions.

[formatc1702]

Would it make sense to only support the current Python version (3.12 as of now), at least officially?

A note in the Readme could state that "WireViz requires Python 3.12. It may or may not work on other versions".

This would speed up the build process by only running it once with the proper version instead of five times (or two, as it is now), as well as keeping local development simple, without having to have all versions installed, and potentially keeping the code clean by not having to support legacy syntax (e.g. type hint syntax added in Python 3.10).

[kvid]

@formatc1702 wrote:

Would it make sense to only support the current Python version (3.12 as of now), at least officially?

If we should support more than one Python version, I would look to common distributions, e.g. for Ubuntu:
The default Python3 versions for the current Ubuntu LTS distributions seems to be:

• Python 3.8 for Ubuntu focal (20.04 LTS)
• Python 3.10 for Ubuntu jammy (22.04 LTS)
• Python 3.12 for Ubuntu noble (24.04 LTS)

See an updated list here: https://packages.ubuntu.com/search?keywords=python3&searchon=names&exact=1&suite=all&section=all

This would speed up the build process by only running it once with the proper version instead of five times (or two, as it is now), as well as keeping local development simple, without having to have all versions installed, and potentially keeping the code clean by not having to support legacy syntax (e.g. type hint syntax added in Python 3.10).

I agree we should limit the number of tested Python versions, and five is probably too many. However, I would consider supporting both 3.10 and 3.12 (personally, I would also like to still use 3.8 because I currently use that for other on-going projects, but I realize it'll reach end-of-life within half a year).

Is it realistic to agree on something about this to be included in #339 as the current Python versions listed in setup.py and our github workflow is a bit outdated (3.7 and 3.8 only)?

Edit: On the other hand, if we test in the workflow only the oldest supported Python version (e.g. 3.8), shouldn't we then expect it to also work in all later minor versions due to backward compatibility (except for effects from bug-fixes, etc.), or have I misunderstood something?

[sb424dat]

I have been using Ubuntu jammy (22.04 LTS) with no problem. I would stress full support for one version (3.8 or 3.7) and stretch to test 3.10 or 3.12. I have spun up many VM in virtual box and had no problem (that I noticed so far).

[formatc1702]

Perhaps if we specify compatibility with versions 3.8 to 3.12, checking new PRs/commits against 3.8 and 3.12 could be enough. For merges into master, it might make sense to enforce stricter checking for all intermediate versions as well to prevent any public blunders.

If it's possible to somehow edit the GitHub workflow config for this, I'm more than happy to integrate it.