Ask HN: Why do programming languages have their own package managers? | Hacker News Reader

Ask HN: Why do programming languages have their own package managers?

4 pointsguhsnamih4 comments

With python I have run into issues where I have multiple packages lying around, those installed by the OS's package manager and those installed by pip of another python.

With node I have always had to install a newer version than that installed by the OS.

ROS seems to take this even further. There is a ros-kinetic-, ros-melodic- series of packages each for a specific Ubuntu release.

There is also perl's CPAN.

OCaml had not one but 2 package managers I think and the only package set that seems to work is that is the default OS install. The others apparently stay up to speed with ocaml updates.

What are possible solutions/workarounds, if at all this is seen as a problem?

View on HN

Why do programming languages have their own package managers?

To simplify dependency management. Most popular and useful programming languages will have a community that creates useful libraries and frameworks that enable a developer to quickly build a solution to common problems or use cases. In many cases these libraries and frameworks will rely on other, lower-level libraries that provide specific functionality. This quickly results in a dependency tree since version X of the higher-level library or framework depends on version Y of lower-level library A and version Z of lower-level library B. Many programming languages simplify dependency management by allowing the programming to declare a dependency on version X of the higher-level library and the transitive dependencies for lower-level libraries A and B are automatically resolved and downloaded.

In the case of python and perl, many operating systems use these scripting languages to power system-level scripts and utilities. This means that parts of operating system are dependent on specific versions of the scripting languages. Historically, that meant that you were stuck with that version of the scripting language and could install packages into the system-wide package directories and use them. Some operating systems (e.g. Debian) include many programming language libraries as operating system packages, effectively bypassing the programming language package management mechanisms. This makes a lot of sense for programming languages that have a strong dependency on the operating system's underlying C libraries. Some of the programming languages have version selection mechanisms that let you install multiple versions of the programming language side-by-side.

More recently, some operating systems have began to separate the operating system's scripting language install from the newer versions of the scripting language that are intended for application development. For example: https://www.redhat.com/en/resources/red-hat-software-collect... This decouples the operating system dependencies from software development tools in an effort to prevent the mess that results from having the operating system and programming environment use the same libraries in an ad-hoc way. See https://xkcd.com/1987/ for a humorous take on the mess that can result if there is not a clean division between operating system scripting language libraries and programming environment language libraries.

Ok, didn't realize that those installed by the OS were for the OS itself and not for the benefit of developers :p. Thanks and yes the xkcd drawing says it all.

Well, historically they were one and the same: for the OS and for development. However with that setup, problems arise if the developer wants / needs to use libraries or frameworks that conflict with what the OS needs or offers.

Part of the reason that containers have become so popular / useful is isolation of the OS and "infrastructure" from the development or production space.

Yes, this is another useful insight. Containers suddenly make a lot more sense to me now.

Reply on news.ycombinator.com