Ask HN: Is there a reason every language comes with it's own package manager?

>> Why could't PIP just be an apt-extension?

Because not eveyone uses an apt-based package manager.

Python runs on quite a few platforms:

https://github.com/python/cpython/blob/main/Lib/platform.py

Apt is not the package manager for most of those platforms. Thus an operating system package manager-based approach would not work for everyone.

That said, several operating systems do "vendor" pip packages so that apt or the equivalent operating system package manager can install a known good version of the package. This approach can introduce problems, but it also can prevent problems depending on the operating system and programming language.

Because of the size of the apt database (just one example, because apt is not the only package manager that needs to be taken into account) to begin with, I imagine anything outside of a distro's specific curation would make it really unwieldy.

Having said that, it would be really nice if you could at least dump the apt, pip, cargo, vim scripts, etc to a common file and use it for setting up new systems with your personal standardized packages and package manager of choice.

Even if you had to use the different apps to parse their own part of it, maintaining all the install info in one portable file would be glorious. Especially for folks with several systems, or systems that are rebuilt often, as seen in Raspberry Pi land, or any kind of lab environment.

Setting up and maintaining a common Linux image, unless it is totally default stock, is really more of a pain than it should be.

Maybe this doesn't matter as much as I think it does, but a lot of languages have duplicate tooling because developers who make and work in a language want to write their tools in the same language.

As a fan of Eclipse at one time, I feel like the non-Java plugins always suffered because the developers didn't know or didn't want to work in Java.

oh look at something like the rust package manager cargo https://doc.rust-lang.org/cargo/ there so much stuff in there specific to rust.

I think this is a great question, but I'd suggest expanding a bit in your post. I think if you expanded your question a bit, this would make it to the front page.

But, to answer your question: In general, every language has its own memory model. This leads to different semantics in how data and APIs are represented. Calling an API (package) from a language that it wasn't written in always requires a certain amount of extra work. (.net was an attempt to solve this, but in practice only C# took off, and the memory model in .net has a lot of tradeoffs that make it a poor "one size fits all" situation.)

But, to build on this, every language generally has a different way of dealing with external dependencies.

So, with it generally being difficult to do something like pull a C# library into Python, or pull a Java library into C, there's really no reason to have a universal package manager.

You'd need to start with a standard way to share libraries across languages. Given how COM and .net fared in this area, I think you'd end up like this: https://xkcd.com/927/

The same reason that there are multiple independent restaurants in a single city.

Because people using those hate updating and sharing their dependencies. A depends on foo version 1.2 and B depends on foo version 1.3 despite foo version 1.4 being available. So naturally A and B both bring their own copy of foo.