how many more years should we keep py2 alive? another 12?
This thread had multiple offers to help him with porting to py3. Waiting for his decision on the subject. And there is only silence. There would be a path forward that is not “oh lets keep all the old stuff alive”.
FWIW: Calibre also said in the beginning “we would rather keep py2 alive instead of porting to py3” guess what. they are now on python 3 as well.
At about 6 mn : application packaging rant
Windows had also the dll hell breaking dependencies.
I’m currently running the Flatpak version of Displaycal on my Kubuntu 20.04 box, with a Spyder2 Express colorimeter.
Zero issues (apart from the flatpack version being somewhat slow to start up)
That’s chickens & eggs issue, if you don’t deliver something that can be worked on the last stable release I don’t see why linux packagers would care about color more than you. And you’ll have the same issue on Windows & Mac at some point. Python2 will not be a possible option. Tools being deprecated is common and in the case we are speaking as been announced years ago. We can’t live forever with some old tools, you certainly can’t ask the packagers and people working on Linux distribution to do additional work for this.
So please, let’s people help you do the Python3 migration, there is very talented peoples just here ready to help I’m sure.
Why not? Windows still runs software from 20 years ago.
Windows APIs from 20years ago are still working this is correct. but posix APIs from 20years ago are also still working. that doesnt mean that each and every of your dependencies (libraries/language runtimes) is included in that API list.
TBH in doubt displaycal needs to be forked.
You can do the same on linux. You just don’t get distros providing this software including security guarantees for the next 4 years to you, because they can’t. You can still get that ancient software, including all of it’s dependencies, and run it on your up-to-date system now. That’s the windows way of things. It’s just that most people on linux don’t like that way.
That’s not the issue. We can make Python2 working on Linux too but it is being deprecated and removed to get a good retirement! That’s not a technical issue but a decision made by the devs.
Sorry but I don’t understand the relevance to what I was asking. It is typical for Windows software to bundle their dependencies. DisplayCAL on Windows bundles a copy of the Python 2 runtime that it needs. Why would that stop being an option?
Then what is?
so who maintains that python 2 fork? so if the next lib, needed to support python2, changes and so do we intree that lib too? lets say py2 does not build with latest openssl anymore? do we fork that too?
The environment around you changes all the time. You either move with it or you get left behind. DisplayCal is currently in the process of getting left behind.
Could @fhoech tell us what is blocking to move on with this?
Demand is a big driving force behind development. This is true for any software: OSes, development tools and also libraries and such. Development brings change. So things (co-)evolve. When you don’t join the evolution, you’re going to be outcompeted one way or another. Either you loose the ability to develop your software further (because your build system is no longer supported), or you loose the ability for your users to use the software (because your software is no longer compatible).
This is not a water tight argument by any stretch (bundling dependencies is certainly possible), but devoutly avoiding change will - one way or another - affect you negatively in the future. The point is, people see this happening and freely offer help to prevent it, but help is consistently declined.
Again, what does that have to do with having that issue on Windows? If there is no active development on DisplayCAL, then there is also no need for a supported “next lib”. For the most part, Windows doesn’t leave working software behind, that’s my (and Graeme’s) point.
See, but my question was explicitly about a point regarding Windows.
Yes there is. because the environment around you changes. And the comparison is not correct either on windows basically every app vendors all dependencies all the time. because they do not have package management. and that means all the burden of making sure you ship security updates for all your dependencies comes to you as the app developer. and that means if you use a 20y old windows app. it might use SSL standards from 20years ago. which many servers will no longer support for good reasons. and tons of other issues.
What comparison?
Does DisplayCAL require SSL to work?
To be clear, we’re talking about a language dependency, not an API dependency…
You won’t find Python-anything in a vanilla Windows install; in a Linux install, the Python language has become an essential part of most distro organizations. That the Python devs chose to migrate to a rev3 of their language had different considerations than ABI breakage, and now we’re seeing the implications.
In Windows, bundling the python2 dependencies in an application installer just affects the visible dependencies for that application; in Linux distros, package maintainers need to use AppImage, flatpack, snap, to do the same thing so they don’t run afoul of the system Python…
You are ignoring the bits of my answer relevant to that aspect (actually every bit of the answer except what you quoted):
That’s what appimages do, that’s what flatpak does. Which @Brian_Innes wrote above that they use without a problem:
So really, you don’t have a problem. If you like running ancient software that bundles everything, and the bloat and security issues (though agreed, the latter likely isn’t a big concern for display calibration) that comes with, you can. That’s another beauty of an open ecosystem: You get a choice.
It’s not that I ignored it, it’s that I didn’t understand why you were saying that. What I quoted was just what I perceived to be a summary of it. You were essentially saying “Linux users can adopt the same approach but they don’t like to”.
So we agree, then. 
That answers my question, thanks.