4 ms·

There are different cadences and roles in play here. Cadences: Distribution - e.g. Ubuntu 21.10, 22.04; RHEL 8.4, 8.5, ..., 9 Library - e.g. simplejson 3.17.

There are different cadences and roles in play here. Cadences: Distribution - e.g. Ubuntu 21.10, 22.04; RHEL 8.4, 8.5, ..., 9 Library - e.g. simplejson 3.17.4, 3.17.5, ..., 3.18.0 Language - e.g. Python 3.8.0, 3.9.0, 3.10.0 (This makes Python particularly annoying because for a C project it shouldn't matter if you used gcc 8 or gcc 9 when producing binaries, but with Python it very much matters which version of Python you run with) Application - e.g. Gimp 2.8.22, ..., 2.9.0 Roles: As a sysadmin you want to use the distro package manager to install tools for administering your system so that you can connect to wifi, monitor resources, etc. As an application developer you want to talk to the language specific package manager so that you can use the latest versions of libraries so that bugs are fixed, and you're not shackled to people using RHEL 6 or 7. As a Debian/Fedora packager you want to talk to the distro because that is required if you want to submit an application upstream to support users who want everything in the distro package manager. As an application packager you may want to talk to the distro because of the above, but you could also target flatpak (or snap) so that you can use all the latest libraries without worrying about packaging for slow moving distributions. As an end user you want to use the distro package manager because that's your embedded mental model and workflow. But you should definitely consider using flatpak (or snap if that floats your boat) so that you can use the release stream wherein the libraries are unpinned from the underlying distribution's cadence. As an end user you should never need to deal with the language specific package manager to install applications or libraries. If you need to install using the language package manager (npm, gems, rocks, cargo, pip) then the application has not really been 'distributed' or 'packaged' imo. If you're doing this, you're off-piste trying out new stuff. There are more details and a great conversation that can flow from this, but language specific package managers are not the antithesis of package management and supplement it; just not for the 'end user' role. Well, yes for the 'end user' role, just not directly.

bregma 5y ago
This is the most insightful comment. All the other observations on this topic (and I've read very many over the years) are akin to the six blind men and the elephant.
hulitu 5y ago
Wouldn't be better if the python programmers did a bit of planning ? Or are the things so boring that every python minor version must be incompatible with other python minor versions.
- fnord123 5y ago
  Features get added. So you can't use a match statement in 3.9 but you can in 3.10. If you write a library you need to be conservative in which features you use or applications can't use you. Why not just upgrade applications ASAP? Sometimes things are removed over three or so versions. So you can't move from e.g. 3.9 to 3.10 without making sure you're importing types from the correct location: https://docs.python.org/release/3.9.0/whatsnew/3.9.html https://docs.python.org/release/3.9.0/whatsnew/3.9.html > Aliases to Abstract Base Classes in the collections module, like collections.Mapping alias to collections.abc.Mapping, are kept for one last release for backward compatibility. They will be removed from Python 3.10. These things are planned. It's just much much harder to handle this because you need the interpreter at runtime while in compiled languages you just use `-std=C99` and you can compile the code and then link.

bregma 5y ago

This is the most insightful comment. All the other observations on this topic (and I've read very many over the years) are akin to the six blind men and the elephant.

hulitu 5y ago

Wouldn't be better if the python programmers did a bit of planning ? Or are the things so boring that every python minor version must be incompatible with other python minor versions.

fnord123 5y ago
Features get added. So you can't use a match statement in 3.9 but you can in 3.10. If you write a library you need to be conservative in which features you use or applications can't use you. Why not just upgrade applications ASAP? Sometimes things are removed over three or so versions. So you can't move from e.g. 3.9 to 3.10 without making sure you're importing types from the correct location: https://docs.python.org/release/3.9.0/whatsnew/3.9.html https://docs.python.org/release/3.9.0/whatsnew/3.9.html > Aliases to Abstract Base Classes in the collections module, like collections.Mapping alias to collections.abc.Mapping, are kept for one last release for backward compatibility. They will be removed from Python 3.10. These things are planned. It's just much much harder to handle this because you need the interpreter at runtime while in compiled languages you just use `-std=C99` and you can compile the code and then link.