On 2020-04-07 19:48:41 +0200 (+0200), Radosław Piliszek wrote:
Jeremy Stanley <fungi@yuggoth.org> wrote: [...]
What you're in effect recommending is that we stop supporting installation within traditional GNU/Linux distributions, since only package management solutions like Docker or Nix are going to allow us to punt on coinstallability of our software.
I think you are taking this a bit too far. System-wide site-packages are an inherently flawed mechanism. Inability to have two different versions of the same library/program is due to this, not packaging. Distros already ship different versions of lower-level libraries, with differing ABI. Sometimes they separate the things in loadable modules with proper dynamic linking chains.
Yes, they do when it's absolutely necessary, but they also struggle to keep that to a minimum and, e.g., only carry one version of libssl at a time outside of transition periods. Every different version of some piece of software a distro carries means that many times they have to work out how to backport things like critical security fixes.
In Python similar can be achieved with venvs (and I know you know that). They exist for a purpose and this is the one.
I don't know of any traditional GNU/Linux distribution which packages virtualenvs of software or considers that acceptable within their main archives. Relying on virtualenv is effectively the same as the Docker/Nix solutions I mentioned above. "Use a virtualenv" is still essentially an argument for giving up on the viability of distribution packages.
Also, those same distros ship other Python projects, we can never ensure this level coinstallability with them even if they could enhance the overall service experience. [...]
We can't, but we do our best to enable them through not pinning the versions we test with in master any more than we have to. It's quite often distro package maintainers ask us on the ML whether we can drop some version cap on a dependency because it's in conflict with something else in their distribution and they don't want to have to carry multiple versions of it.
Separate thing is that not all OpenStack software is packaged in the main distros. So in their case this is just wishful thinking: package me, I'm ready for the traditional packaging world where we drop everything in one big namespace*. :-) [...]
Most OpenStack services, libraries and clients are packaged in Debian, Ubuntu, and RHEL (though via RDO in that case?). There are probably plenty more examples I'm just not aware of. -- Jeremy Stanley