Hacker News Reader

Comment by jrmg | Hacker News Reader

And since before that, when we started turning to additional packages managers installed with package managers. Pip etc. mean that an “apt upgrade” isn’t enough, when it really “should” be (used to be) in a well managed system.

Then we layered _another_ level of package management on top with Flatpak etc.

I don’t think anyone has _really_ been - in practice - able to understand how many versions of Python (or shells or ruby or Perl etc…) are installed on any system for a decade or two now.

[Edit to add: and I forgot entirely about venvs (and other language’s equivalents). We put package managers into packages! Now there can be a different version of every package for every script on your system. In every container. And Python even has more than one venv system to choose from!]

[Yes, I use all these things - it’s so hard _not_ to and still use modern software or participate in modern software development…]

View on HN

It's funny that no one seems to even consider using the distro package manager when it's time to complain about Python package management again. The deployment environment is usually well-known thus scriptable, and developers can be expected to know how to install packages on their own distros. And, of course, if the package is deployed as part of a distro, everything is taken care of by the distro people.

Flatpak is somewhere in the middle because it can and does centrally update dependencies, though they are packaged in larger boxes and it's tempting to include more exotic stuff in the app package instead of creating and maintaining a separate Flatpak shared with other dependees.

Nobody seriously considers it because usually, especially in enterprise distros, the major versions are years out of date and missing many features. And many smaller packages just won't be available. Even for something as major as Django it just wasn't viable to use the OS package manager when I tried it in the Debian 8 and then 9 days.

I've had Python software that just expected certain packages several times at different $work and it's also how I use KDE's kde-builder, which can helpfully suggest package names for a few popular distros and maybe also for pip. I guess these people just don't know that they are doing it wrong /s.

Only one company I've worked at maintained their own distro packages for deploying services. That was 13+ years ago. Every company since then had a containerized deployment strategy, some better than others. My most recent employer went through a massive effort to implement "golden base images" and tooling to ensure when the base image is updated all the dependents are rebuilt and redeployed. Most don't do that.

Imagine the problem that required virtualenvs (or containers). Distro packages don't work well with that. Plus the packages are already outdated most of the time. Unless by "distro package" you mean packaging an entire environment as a distro package, but you'd run into the same problems of multiple installs there.

Reply on news.ycombinator.com