Hey fungi, Jeremy Stanley <fungi@yuggoth.org> wrote:
Just to be clear, we didn't add rules about coinstallability to make *our* upstream lives easier. We did it so that downstream distros don't have to provide and support multiple versions of various dependencies.
Indeed, these are not for us but for potential downstreams.
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. In Python similar can be achieved with venvs (and I know you know that). They exist for a purpose and this is the one. 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. What is done then? Isolation. :-) Same story if said distro needs to ship some old version of Python package for its internal usage.
You're *also* saying that our libraries now have to start supporting users on a broader variety of their own old versions, and also support/test working with a variety of different versions of their own dependencies, or that we also give up on having any abstracted Python libraries and go back to re-embedding slightly different copies of the same code in all OpenStack services.
No, why? Voting for containerization and abandonment of strict coinstallability enforcement does not invalidate the purpose of these. Again, the strength is in well-defined interfaces, not reliance on exact versions of every library. Program to interfaces, test the interfaces, live a happy life. All that said, I am not for dropping this all right away. This needs to take time and *will* take considerable time for sure. There could be a staged approach where we allow projects to drop out of coinstallability constraint (looking at Ironic now). 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*. :-) For reference you can inspect the non-buildability patterns of Kolla for the binary flavor: common (rhel+debuntu): https://opendev.org/openstack/kolla/src/commit/f1f1d854594da23321ad94ae6358e... debuntu specific extra: https://opendev.org/openstack/kolla/src/commit/f1f1d854594da23321ad94ae6358e... * As long as you only care about OpenStack because I'm gonna break your X. -yoctozepto