Comment by StefanKarpinski | Hacker News Reader

Comment by StefanKarpinski | Hacker News Reader

Parent Full thread

StefanKarpinski

In this vision of the world, how does one install Python packages on Windows or MacOS? Or even on Linux distros that don't use RPM or Apt?

Let's suppose that some language decides to use the system package manager to install packages. They add support for RPM. Then for Apt. Then for Portage. Then for Pacman. Then for Zypper. If they're not too exhausted at this point and have any spare time between trying to keep things working on every flavor of Linux around, they decide they want people to be able to use their language on Macs. So they add support for Homebrew. Except that some Mac users don't like Homebrew and want to use MacPorts. Some others use Fink. So the intrepid language devs add support for those two as well. Now our poor maintainers are supporting eight system package managers that all have their own quirks and oddities that makes keeping all this working a massive nightmare. And all of this work is not done just once, it has to be repeated for every single package that someone creates for the language.

Oh wait, but users still can't even install language packages on Windows! You know — the most popular OS of all. Oops.

Perhaps this sheds light on why no programming language does it this way. Languages have to allow package installation on not only your personal favorite distro of Linux, but also on vastly more popular OSes — Windows and MacOS — that don't even have standard package installers that they can use. The only scalable way to do this is to allow installation of the language and its internal package manager on each platform and then use a consistent internal system that is abstracted from the platform for installing language packages. Which, not coincidentally, is exactly what every programming language does. Python is a little odd in that it doesn't have a single blessed package manager, and that causes a lot of problems, but using the system package manager is not the solution.

I should clarify that I'm not saying remove the ability to install packages into a venv or even straight into the system.

However this article is about making pip to better interact with the system package manager on Linux. To me this seems like a bandaid solution instead of generating a rpm/deb file and installing this. You essentially get protection against overwriting other package files, but also protection against the package manager overwriting pip installed files for free. Instead we put a hack in place to add another db (a file) to check for both the system package manager and pip.

Clearly I'm missing something but why is nobody proposing this solution at least for this context?

I think it could because there are much more packaging format other than rpm/deb. What about Arch Linux, Gentoo or even BSDs? It is easier to maintain packages in the same way across platform.

As I said before you can still provide the other method for installing packages, but at least you cover >90% of all Linux installs (and I'm an arch user).

The thing is simply if I need to install system packages I want them to show up in the system tools. The problem with pip and co doing their own thing is it never shows up in the system tools. That's the same on windows, I don't see it those in the software manager. As a user/admin that means I now need to keep track of one more tool to see what is installed on my system.

So the argument is because Windows and osx don't have sane (or any) package management everyone else has to suffer? The work having gone into reimplementing python package managers alone would have been enough to implement an interface for every one of the major Linux package managers many times over (there are also several translation tools available as well).

I do concede that Linux package managers should make it easy to install as users as well.

You say that as if fairness has anything to do with it. It doesn’t. Programming languages need to let people install packages on all the major platforms. End of story. Any approach that doesn’t make that practical and scalable is dead in the water regardless of fairness. Even just on Linuxes, there’s enough package manager variation to kill that idea for installing language-level packages with all the different system-level package managers. If you want to lobby all the Linux distros and Apple and Microsoft to adopt a common package installation standard, that would be great but until that happens, that’s just not a feasible way for languages to install packages.

Reply on news.ycombinator.com