[lizard]

> It's hard to tell what your issue with backward compatibility was exactly without examples.

I can't speak for worik, but it sounds like they are talking about backwards compatibility as a user of applications written in Python. I.e. you can't just go to python.org, download the latest version of Python, and expect run any Python program because that code could be using a function or library that was recently removed (or in their case, upgrade Debian which presumably packaged a newer version of Python by default). This is compared to a Windows application where the same .exe will generally work everywhere (and failing that, there are compatibility options).

It's also common in Python to declare minimum versions but not usually maximum, so requirements end up looking like "Python 3.8+". So from a user, or Linux package maintainer, perspective, they wouldn't even know it uses something that has since been removed.

Generally speaking, these kinds of issues are considered a bug in the application and should be filed when the maintainer. Though that's of little help if the maintainer is slow to act.

Of course, it's also relatively easy to just install multiple versions of Python these days, then have specific binaries, e.g. python3.10 and python3.11, or a launcher like built into the Windows installer, e.g. py -3.10 or py -3.11

[worik]

I have said two examples: mod-ui: https://github.com/moddevices/mod-ui/issues/145#issue-203423... and Yocto, no link for that.

Installing multiple versions of Python? You have got to be kidding. But I did try that. I cannot remember the details, all I remember was the inability (a software hellscape) to get a system that had to be built with one version of Python to play well with a package that had to be built with a later version.

It is 2024, what have they learnt? Just keep backward compatibility, it is not that hard.

[lizard]

> Installing multiple versions of Python? You have got to be kidding.

Why? There's some overhead because it's not like everything has changed between versions, but otherwise it's a very clean way to provide exactly what you need without having to maintain backwards compatibility in future development.

Mind, as long the the Python code you're running _isn't_ using removed or significantly changed function, you can absolutely run code written for Python 3.6 with the 3.8 interpreter, and so on. If I recall correctly, this is _why_ it's uncommon to specify maximum versions in Python packages: unless it is specifically incompatible with a change in a newer version it should generally be assumed to work, and pinning a maximum version would just cause it to fail for no reason.

In your Issue with mod-ui, they specifically say

> mod-ui is not compatible with python3.11, so this wont work.

but your second attempt is still using 3.11 based on your output. It's a shame this isn't better documented since it seems to be known, but that seems like an issue with the project, not Python?