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)
You just gave me PTSD, fuck bazel
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:
- Why? That feels like trying to write a single style sheet for both English and Mandarin.
- That might explain why it’s so confusing. I surmised: I has to bend over backwards to support all these different languages and their different module and packages architectures. And it doesn’t manage to hide that complexity from the user.
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
Throwing in my two cents:
I would imagine package managers are because of C and C++ not having package managers. I remember 20+ years ago before package managers were a thing, before the Debians, Ubuntus, and Arch (btw)s (before autoconf and configure), when we would download software and have to compile it ourselves, and the lack of reliable means of knowing what dependencies were needed to compile said software. Repeat this ad nauseam for each dependency that itself had dependencies.
It was Hell.
~I for one am grateful for my dependency-resolving overlords. 🙇♂️~
IIRC before first Debian, ny Slackware’s packages where plan .tar.gz files
This is how I got started with Linux. On windows to play media you needed various codec packs and loads of other bullshit. Then I discovered VLC that just worked, and was free? What’s this opensource thing is it like freeware? Then my whole computing world opened up.
i dont understand why you are confused. are you suggesting they should be in the OS? so each library has to be managed at least 6 times and then the ides and language tools have to support all these different stores? i bet ci/cd would just be awesome
or are you suggesting that all language maintainers work together in harmony and support one another?
C and C++ dont have package managers because they are older than the concept.
Having a project’s dependencies in the project dir also makes more sense imo, because these are generally packages that nothing else on the system needs.
Git submodule
As people grow up, they stop believing in magic
It’s because it’s the greatest thing since compilers. Having a clear “this is how packages interact” rules and “autodownload dependencies” solves a massive headache. C/C++ packages are basically the wild west.
CPAN for perl was the first one and it was very successful so got copied.
separate from the distribution or OS package manager.
Because it is way easier to manage them this way rather than have every distro package repo also support them. Additionally, windows and Mac are also targets and they don’t have built in package managers.
C and C++ are the only exceptions
It is not as popular but https://conan.io/ exists. Personally, I miss working in c++ because the lack of a built in package manager made people manage dependencies more thoughtfully. It was not without tradeoffs but I preferred that world to adding a dependency being one command away.
the lack of a built in package manager made people manage dependencies more thoughtfully
Unless your colleagues are idiots and now you get to maintain your own homemade “package” “manager”. I find conan to be bidet in a world of diarrhea.
Additionally, windows and Mac are also targets and they don’t have built in package managers.
Windows does have a built in package manager: winget.
Sure, but it’s only 6 years old, much newer than every one in this post, to my knowledge only has applications rather than libraries, and sources packages from the windows store or the community repository which is just manifests rather than the actual code or binaries.
In other words you’re technically correct, but it’s rather irrelevant
Because you don’t want a single operating system manage the entirety of the Rust eco system. They need to be its own thing, so it can be used and managed by an individual team independent from any operating system.
Do any serious portable project with C and you’ll see why. You’ll either need to vendor in all the code you want to link against, or you’ll constantly have compilation issues when the OS provided library differs (or doesn’t exist at all) from the one you have on your dev box.
Because professionals have standards.
I think that nix might be on the way to solving that problem. It does need a lot of work though.
Now you have two package managers. The problem is that Nix needs to create a folder structure that matches what your language package manager wants to see.
Even if the language package manager goes away, languages have slight differences that can’t be totally abstracted away. C/C++ have .h and .c files. JS has its own thing, C# has a .dll. Each language has difference opinions on how symbols get resolved.
lowers barriers to adoption of the language and its ecosystem
Reminder that TIOBE is ass and shouldn’t be used for basically anything except for who to target advertising to.
In the case of Rust, it makes sense both as a UX win and a way to abstract certain requirements of the build system. Languages don’t agree on how to do things like linking packages into a binary or versioning packages. If Rust left all of that unspecified, we’d probably have multiple competing package managers and ecosystems.
The OS package manager is basically the C/C++ package manager. :P They all have OS level aspirations. Don’t let them.
You want some way to define package versions in your repository, so that you can check out an earlier commit or a different branch and still have a working build. Because you do often need to adjust the code in your repo when dependencies get updated.
And going upwards from there, I think that languages are just a point where it’s quite natural for this to be solved, since the language creators care to build up an ecosystem and it does help when you can make language-specific assumptions.
I do think, it’s possible to create a package manager that spans across programming languages, like Nix is starting to be viable for.
But you need that to be ready when a new programming language is starting to take off. For all the languages you listed, that choice was made many years ago and you can’t easily reverse it.
