this post was submitted on 06 Aug 2026

86 points (97.8% liked)

Programming

28009 readers

447 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

Why do so many programming languages have their own package manager? (sh.itjust.works)

submitted 2 days ago by DeltaWingDragon@sh.itjust.works to c/programming@programming.dev

41 comments fedilink hide all child comments

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 npm for 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 get command

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

all 42 comments

sorted by: hot top controversial new old

[–] trem@lemmy.blahaj.zone 5 points 21 hours ago

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.

[–] olafurp@lemmy.world 28 points 1 day ago

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.

[–] QueenMidna@lemmy.ca 14 points 1 day ago

Because professionals have standards.

[–] tatterdemalion@programming.dev 7 points 1 day ago

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.

[–] netizen@programming.dev 29 points 1 day ago

As people grow up, they stop believing in magic

[–] dohpaz42@lemmy.world 48 points 2 days ago (2 children)

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. 🙇‍♂️~

[–] Theoriginalthon@lemmy.world 6 points 1 day ago

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.

[–] netizen@programming.dev 8 points 1 day ago

IIRC before first Debian, ny Slackware's packages where plan .tar.gz files

[–] staircase@programming.dev 49 points 2 days ago* (last edited 2 days ago) (4 children)

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)

[–] FizzyOrange@programming.dev 2 points 1 day ago

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.

[–] onlinepersona@programming.dev 6 points 1 day ago* (last edited 1 day ago) (1 children)

Care to elaborate?

[–] staircase@programming.dev 13 points 1 day ago* (last edited 1 day ago) (1 children)

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.

[–] onlinepersona@programming.dev 3 points 1 day ago (1 children)

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.

[–] RaphaelSchmitz@feddit.org 1 points 1 day ago (1 children)

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.

[–] kuberoot@discuss.tchncs.de 1 points 12 hours ago

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.

[–] scottmeme@sh.itjust.works 12 points 2 days ago

You just gave me PTSD, fuck bazel

[–] tatterdemalion@programming.dev 1 points 1 day ago (1 children)

I thought Bazel was just a build system, not a package manager.

[–] staircase@programming.dev 1 points 1 day ago* (last edited 1 day ago)

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

[–] onlinepersona@programming.dev 13 points 1 day ago (1 children)

I think that nix might be on the way to solving that problem. It does need a lot of work though.

[–] chaospatterns@lemmy.world 3 points 1 day ago* (last edited 1 day ago)

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.

[–] terabyterex@lemmy.world 35 points 2 days ago* (last edited 2 days ago) (2 children)

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.

[–] Ghoelian@piefed.social 6 points 2 days ago (1 children)

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.

[–] LodeMike@lemmy.today 1 points 1 day ago

Git submodule

[–] 30p87@feddit.org -4 points 2 days ago* (last edited 1 day ago) (1 children)

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 pypi (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.

[–] FizzyOrange@programming.dev 3 points 1 day ago

I don't know why you think Python is fine but Typescript isn't. With modern Python best practice (project.toml and uv) they have basically the same behaviour and caveats. Python is actually a little worse because most Python packages don't use semver.

[–] Feyd@programming.dev 27 points 2 days ago* (last edited 2 days ago) (2 children)

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.

[–] Miaou@jlai.lu 3 points 1 day ago

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.

[–] Pamasich@kbin.earth 3 points 1 day ago (1 children)

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.

[–] Feyd@programming.dev 5 points 1 day ago

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

[–] CameronDev@programming.dev 18 points 2 days ago

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.

[–] TrickDacy@lemmy.world 9 points 2 days ago (1 children)

What would be the alternative, exactly?

[–] one_old_coder@piefed.social 6 points 2 days ago* (last edited 2 days ago) (2 children)

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.

[–] kuberoot@discuss.tchncs.de 1 points 12 hours ago

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.

[–] TrickDacy@lemmy.world 2 points 1 day ago

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

[–] spj@sh.itjust.works 9 points 2 days ago

Reminder that TIOBE is ass and shouldn't be used for basically anything except for who to target advertising to.

[–] crystalwalrus@programming.dev 9 points 2 days ago

lowers barriers to adoption of the language and its ecosystem

[–] bluGill@fedia.io 7 points 2 days ago

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.

[–] arran4@aussie.zone 7 points 2 days ago

The OS package manager is basically the C/C++ package manager. :P They all have OS level aspirations. Don't let them.

[–] hallettj@leminal.space 6 points 2 days ago

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.

[–] rumschlumpel@feddit.org 6 points 2 days ago* (last edited 2 days ago)

A language's packages need to be in lockstep with the language's version, and they usually depend on each other, too (to a much higher degree than they depend on programs/libraries from other languages, not counting stuff like C that many higher-level languages are built on).

[–] Reptorian@programming.dev 1 points 2 days ago

Well, as a user of DSL (G'MIC), I'm happy without packages.