I meant that maybe one target doesn’t support Python 3 (e.g. older Debian) and another doesn’t support Python 2 (i.e. a bleeding edge distro). There were tons of libraries that supported both at the time, though it wasn’t due to distro compatibility. I used it as an example because the transition was so rocky and most people were aware of the issue.
But the same idea can happen when using newer compiler features or something. If I need a newer version of something than a distro supports, my options are:
maintain an older version of the tool that works with whatever the distro supports
campaign to get that version upgraded
not ship on that distro
ship with my special dependencies (e.g. use a FlatPak)
Of those options, the last is a lot more attractive and requires the least work. Ideally these are rare exceptions, but it should absolutely be an option.
The Python 2 -> 3 transission was a mess. Same with GTK2 -> GTK3. Lots of young developers think they can just ditch legacy and do all new and shiny. Learning it is a mistake to disregard legacy is part of maturing as a developer.
Debian has packaged libs as python-libname and python3-libname. There is a few python2-libname but python2 is on the path to removal.
Right, but they didn’t support Python 3 for a while. And with 5-year release cycles, it’s entirely possible that you’ll have a situation where some distros don’t support Python 3 and some don’t support Python 2. Or any other platform (e.g. maybe you need a shiny new C++ feature, but certain distros don’t support that version yet).
So those distros can either not include those packages (seems to be the current approach), add a feature mid-cycle (pretty rare, though people do make repos that do so), or allow some method of bundling it with its unsupported dependencies.
Debian isn’t 5 year releases… it’s more like 2, and that’s Stable. The whole point of stable is to be boring but reliable. Testing is more fun, and Unstable more fun still. Mixing in some Experimental for even closer to the edge. There is also Backports to bring a more stable base closer to the edge.
Having grown up on RISCOS with app folders and then gone to Windows, then wondered Linux land until finding Debian was my home, I worry about the movement back to basically app folders. I love the order of Debian. All those packages, with their dependencies, their build dependencies and source, all in database, I count with Wikipedia as achievements of man kind.
I meant the support timeline. Debian releases are supported for 5 years. You can basically skip an entire release and still be completely supported with security patches.
Perhaps you should consider the alternative, that it’s the lack of consistent dependencies across target distributions that’s the problem. Some of it is certainly fixable on the development side, but a lot of it is just the complexity of managing a software project that is expected to run in multiple very different environments.
I meant that maybe one target doesn’t support Python 3 (e.g. older Debian) and another doesn’t support Python 2 (i.e. a bleeding edge distro). There were tons of libraries that supported both at the time, though it wasn’t due to distro compatibility. I used it as an example because the transition was so rocky and most people were aware of the issue.
But the same idea can happen when using newer compiler features or something. If I need a newer version of something than a distro supports, my options are:
Of those options, the last is a lot more attractive and requires the least work. Ideally these are rare exceptions, but it should absolutely be an option.
The Python 2 -> 3 transission was a mess. Same with GTK2 -> GTK3. Lots of young developers think they can just ditch legacy and do all new and shiny. Learning it is a mistake to disregard legacy is part of maturing as a developer.
Debian has packaged libs as python-libname and python3-libname. There is a few python2-libname but python2 is on the path to removal.
Right, but they didn’t support Python 3 for a while. And with 5-year release cycles, it’s entirely possible that you’ll have a situation where some distros don’t support Python 3 and some don’t support Python 2. Or any other platform (e.g. maybe you need a shiny new C++ feature, but certain distros don’t support that version yet).
So those distros can either not include those packages (seems to be the current approach), add a feature mid-cycle (pretty rare, though people do make repos that do so), or allow some method of bundling it with its unsupported dependencies.
Debian isn’t 5 year releases… it’s more like 2, and that’s Stable. The whole point of stable is to be boring but reliable. Testing is more fun, and Unstable more fun still. Mixing in some Experimental for even closer to the edge. There is also Backports to bring a more stable base closer to the edge.
Having grown up on RISCOS with app folders and then gone to Windows, then wondered Linux land until finding Debian was my home, I worry about the movement back to basically app folders. I love the order of Debian. All those packages, with their dependencies, their build dependencies and source, all in database, I count with Wikipedia as achievements of man kind.
I meant the support timeline. Debian releases are supported for 5 years. You can basically skip an entire release and still be completely supported with security patches.
Just another way it is awesome.
Yes, it is awesome, I’m just saying that supporting that is a big ask for a software vendor, so containerizing dependencies is a viable workaround.
I’m always going to see it as second class and avoid that software when ever I can. I see it as symptom of either rotting software or poor developers.
Perhaps you should consider the alternative, that it’s the lack of consistent dependencies across target distributions that’s the problem. Some of it is certainly fixable on the development side, but a lot of it is just the complexity of managing a software project that is expected to run in multiple very different environments.