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
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.
I got the same feeling that it shouldn’t be rocket science. Then again, I’m most experienced with C#, which is just a very clean and professional ecosystem, and I often experience that other languages can feel rough around the edges in comparison. E.g. in npm JS, different package managers create entirely different folder structures, even though the build system is 100% the same!
So maybe a package manager for C# would be straightforward, while npm JS would require a bunch of research about what happens behind the scenes.
And if other languages are similar to npm JS, it’s easy to imagine that your want to keep languages separated for cleanliness - but then you kinda just get a bunch of one-language-package managers in a trenchcoat, so why even bother. OR you have the same code handling it all, becoming a bit of a mess.
Worth noting is that C# generally uses compiled libraries, not quite binaries but CIL rather than source code, so that’s what you get when adding references and NuGet packages. And at the same time, compiled C# files include a lot of metadata about the code, like class structure and method signatures, so one .DLL is all you need to use a library.
NPM is a more complex situation. To say there is one build system is already misleading, since there isn’t a build system built into JS - packages can be source distribution, or they can use a variety of tools, minifiers, packages for web or for Node, and occasionally include native libraries/binaries or otherwise compile native code from other sources.
I think generally new languages have their own package managers primarily because older languages weren’t planned for convenient dependency management, so solutions for that are stapled on top of their stuff, aren’t compatible with existing libraries, often have some annoyances, and there are often multiple alternatives that were independently developed. On the other hand, new languages can just plan things out from the start, tweaking the language to work well for libraries, and establishing a single tool to avoid fragmentation.