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 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.
As people grow up, they stop believing in magic
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. 🙇♂️~
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.
IIRC before first Debian, ny Slackware’s packages where plan .tar.gz files
It’s because every ecosystem wants its own GovOS.
Because professionals have standards.
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.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.
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.
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.
What would be the alternative, exactly?
Each project would have to reinvent the wheel and make packages for the 10 most popular Linux distributions (every one of them being different, DEB, RPM, Arch, etc.), Windows 10, Windows 11, macOS latest version, macOS previous version, and macOS future version.
Also you would need 10 virtual machines to test on Linux, 2 virtual machines for Windows, and 3 Apple computers. That would be so easy.
Yeah, it’s so annoying how every crossplatform project is having to do that, it’s such a burden on all those indie developers all managing so much hardware and automation to support those platforms. /s
I think I’ve seen the same argument against Linux package managers in general, and it’s bullshit in the way that it’s not on the projects to package for each distro, it’s on the project to provide a functioning build system, or at least binaries, and from there it’s on the distribution maintainers to figure out packaging.
But also, in cases where packaging is more complex than just one dependency system for a whole language, it would be beneficial to have one unified system - if all languages are packaged in a unified way for specific system package managers, then you only need to develop a system for them once across all languages, and then you might have one system you need to plug your project into, and from there it could be automatically packaged into all those systems.
Haha sure I guess. I think before package managers people used a hodge podge of manual systems to manage dependencies and it sucked. Your way sounds even worse tbh
Reminder that TIOBE is ass and shouldn’t be used for basically anything except for who to target advertising to.
lowers barriers to adoption of the language and its ecosystem
For the simple cases, a language package manager is easier to write and makes things easy. However, simple cases aren’t at everything and for the more complex cases, such as what C and C++ is commonly used for, a language package manager is not complex enough to handle all the little weird special cases and so it would be a bad idea.
Those who use a language for something complex will not use the built-in package manager. Realistically though, very few people are writing complex software and so this objection, although real, is probably a pedantic thing that doesn’t affect you.
The OS package manager is basically the C/C++ package manager. :P They all have OS level aspirations. Don’t let them.
I agree that this doesn’t seem necessary. Personally I think Nix would be a good candidate for dependency management that works consistently between languages. I think that may be partway set up for Haskell, and I’ve noticed that nixpkgs has a good collection of Python dependencies. But for most cases the Nix flow currently usually involves using the language’s bespoke dependency manifest to generate a Nix expression that downloads dependencies from the language’s bespoke package repo.
One advantage of Nix is that you don’t need all packages in one repo. Nixpkgs is mostly geared for the NixOS Linux distro. Each language ecosystem could have its own repo if that makes the most sense, with Nix being the common connective language.
