No longer working on Arch Linux: Required Python 3.11

[es20490446e]

Traceback (most recent call last):
  File "/usr/bin/displaycal", line 4, in <module>
    from DisplayCAL.main import main
  File "/usr/lib/python3.11/site-packages/DisplayCAL/main.py", line 27, in <module>
    raise RuntimeError(
RuntimeError: Need Python version >= 3.8 <= 3.10, got 3.11.3

[es20490446e]

Probably it shall only check for: Need Python version >= 3 < 4

[boreq]

I would like to propose not checking the Python version. If the program will error out that is great but most likely it will just work, at least let me try.

[p5k369]

@es20490446e use the dev branch instead. Take note that we can not support you in case you experience this problem via arch package installation.

[es20490446e]

Ummm 🤔

So where shall ALL Linux distros build their packages from? Develop? Won't it be a bit unnecessary having to upgrade on an arbitrary commit instead on the latest release?

Why having both "main" and "develop"?

What's the purpose of setting "py_maxversion" other than "4.0", if any Python future point release is retro-compatible with the previous?

[es20490446e]

Downstream: https://bugs.archlinux.org/task/78430

[p5k369]

Hey @es20490446e sure, but take note that the latest release does not resamble the latest commit. In various distribution dev would be called unstable I guess. Hey @eoyilmaz what do you think about merging dev into main for a release?

Why having both "main" and "develop"?

It's a maintainer's decision and from his perspective it makes sense since he is not the only one approving pull requests. The python version limit corresponds to the versions that are automatically tested against.

[eoyilmaz]

Hey @p5k369 yeah sure, it is time to do a new release 👍

[es20490446e]

I suspect that limiting the max version, lower than 4.0, will constantly break the software.

Also if code is tested against 3.10, for example, it shall always work on 3.11.

Because that's what semantic versioning is about.

[p5k369]

Hey @es20490446e do you program in python? Thats not how it works. Python 3.12 will break your python 3.11 code if you make use of the distutils package for example, simply because it gets removed.

edit: or in other words, the code will break either way, but by setting a max version the developer can tell the user what to do, until a new release is available

[es20490446e]

Currently each time the python package is upgraded, displaycal will stop working. And the packager won't notice it.

Hence that version checking is preventing no mistake, but instead forcing the packager to take an extra step of removing the check downstream.

Plus the package may take a few weeks to be upgraded in the distro, and to work again. Meanwhile I have personally checked that the user won't have a simple way to work-around this.

[p5k369]

Hey @es20490446e, I kind of understand your point from a user perspective but I do not understand why it isn't possible to make a package in arch with linked dependencies, that is the purpose of a package, right?(I have to admit being not familiar with the arch package system). The gentoo ebuild (which is the arch package equivalent) works until now, without any hassle for the user, because the packager added PYTHON_COMPAT=( python3_{9..10} ) to his ebuild.

Hence that version checking is preventing no mistake

You wouldnt notice, because the code wont be checked by the packager, in an easy case python will just crash for example if an import is missing, a lot trickier would be if a return type of a function got altered. Then the program could work as before but does something different.

Plus the package may take a few weeks to be upgraded in the distro, and to work again. Meanwhile I have personally checked that the user won't have a simple way to work-around this.

That might be true for arch packages, but displaycal is distribution independent and a lot of support has to given to people that install via pip or try to run it from sources. If you have (or want) to give support you want to reduce the impact of dependencies or their different versions.

[es20490446e]

Counterintuitively, using the last version only has huge advantages. For example:

• You test bugs against the last version, which is the one supported by the original developers. Hence you don't need a separate bug report or patching, which rarely take place anyway. You deal with the people that maintain and know the software inside out.

• Bugs don't accumulate. You deal with them as they appear, versus waiting for the next release where suddenly all errors come together.

• You don't have to maintain and compile several versions. For example, for Python, compiling multiple versions take a big load of time. By having only the last version packages can be upgraded easily and quickly.

• It's simpler to patch a particular package for compatibility, than maintaining all the old versions.

In summary:

People tend to believe that having older versions is more reliable. When in practice you are retaining all bugs to come all together, in all shorts of shapes, while making it harder to quickly fix them.

Tomorrow wave

[eoyilmaz]

DisplayCAL 3.9.11 has been released https://pypi.org/project/DisplayCAL/

[p5k369]

Hey @es20490446e

Counterintuitively, using the last version only has huge advantages.

I already wrote, this is a maintainer's choice which is quite common when different people are allowed to approve pull request. However you are completely free to build packages from the dev branch if you wish.

[eoyilmaz]

Closing this as 3.9.12 is released and there is no activity on this ticket for a long time.