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
As people grow up, they stop believing in magic
I think that nix might be on the way to solving that problem. It does need a lot of work though.
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
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.
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
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:
- 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.
You just gave me PTSD, fuck bazel
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.
And I prefer C/C++ and Python due to that.
Eg. JS devs need to version pin in NPM to not expose users to compromised packages. That means that, from now on, they need to be active at least every week and update the pinning to not expose users to vulnerable packages. Meanwhile, the users need to be on-edge about the dev actually being active, and, still, for every vulnerability and compromised package, need to scan their whole system for files relating to that package. And of course, that means a very long fix path of Vuln discovered -> Vuln fixed -> Dev knows that one of the dozen packages they use needs updating -> Dev updates -> Package managers updates -> User updates.
It’s a horrible experience for sysadmins. I’m actively switching to alternatives and rewriting smaller things in C++, because everything I’ve written in the latter has never broken in years, without recompilation, because the ABI stayed the same for all libraries, while the libraries get carefully curated by a dedicated team. And as soon as a vulnerability/backdoor is found and fixed? sudo pacman -Syu. nothing more, nothing less. Fix path: Vuln discovered -> Vuln fixed -> Package managers updates -> User updates.
Looking at more than just binary files in repos: I’m also actively rewriting PKGBUILDs to use the native python packages instead of building a venv, because that just works better in my experience. I’ve never had issues with incompatibility between python-* packages, simply because they are build for each other. And I mean, it took 30 minutes to build a component that converts a requirements.txt, which requires you to trust the dev (to be active) and npm (which you can’t trust), to a collection of pacman packages. Universally applicable to all requirements.txt and uncomplicated. So yeah, idiots can continues using pip, I laugh with a list of packages neatly curated by a dedicated team.
deleted by creator
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.
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.
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.
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.
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.
