cross-posted from: https://sh.itjust.works/post/64685863
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


If you’ve ever tried using bazel, you might understand why writing a single package manager for multiple languages is a bad idea (at least, that’s why I assume bazel is so god-awful)
Care to elaborate?
It’s been a while since I used it in earnest, so my memory is hazy enough that I can’t be specific. One of the largest pieces of work I’ve done in C++ was not writing C++, but working out how to ask bazel to build a single shared library that imports other bazel libraries. I’ve never used such a confusing and frustrating package manager. It was frequently unclear how to do things, despite the project having quite a lot of documentation.
When I read it supports multiple languages, I had two thoughts:
Thank you. I didn’t expect that because I assume that packages are basically the same everywhere you go (at least in my experience). And managing them is basically solving dependency trees, then downloading files and putting them in the right place for the import system to find them.
But my experience with programming languages is limited. I haven’t found a language that doesn’t work this way.
It’s not that it’s a bad idea, it’s more that it’s basically impossible at this point.
Bazel can’t use Cargo, CMake and so on for downloading & building packages because it is trying to do cross-language builds the right way - a single build graph that includes everything. No other third party package managers/build tools actually exposed their build graphs - only commands to perform builds, which are too coarse for Bazel.
To put it simply, its necessary if you are doing things at the scale of Bazel.
I thought Bazel was just a build system, not a package manager.
Hmmm, you might be right. It’s definitely a build system. I’m trying to think if it’s a package manager, and if it’s not, what is playing the role of the package manager.
EDIT seems to be both, which admittedly makes my point less relevant.
https://moderncppdevops.com/pkg-mngr-roundup/#build-systems-and-environment-managers