Lots of programming languages have their own package manager, separate from the distribution or OS package manager.
Going loosely from the TIOBE index:
- Python has Pip
- C# has NuGet
- Javascript has
npmfor Node.js - Visual Basic also uses NuGet
- R has a repository of packages that can be installed by running
install.packages("something")in R - Rust has Cargo/Crates
- Go has the
go getcommand - Swift has its own package manager
swift package - Ruby has RubyGems
- Java has Maven and Gradle (not sure if they are full package managers, or build automation tools with dependency resolution)
- PHP has Composer for managing libraries and dependencies
- C and C++ are the only exceptions I can think of, off the top of my head; libraries are managed by, and coupled to, the operating system
I wanna tackle the question „What’s the benefit?“ first. Imagine one package manager with one repository to serve multiple languages. Now I want to install a library for my rust project and I include a Python library (maybe by accident, maybe intentionally). What’s supposed to happen? Rust can’t call into Python so it can’t work.
So ideally libraries would have to be scoped to specific languages, and now we’re almost back to the original situation but with a worse package manager.
And what if I want to include a C++ library in Rust? If that library isn’t heavily using external C then the ABIs are going to be incompatible, and I still can’t use the library properly.
Does that fictional generic package manager also have to ensure compiled languages compile in a ABI compatible manner automagically?
And what is the OS package manager gonna do when you have two separate projects requiring two different versions of the same dependency?