That sort of package manager has a totally different purpose and does absolutely nothing to help build your code, manage dependency versions, or control how dependencies are built.
They clearly do manage "dependency versions" (that's what they do: that's the primary purpose of say, apt). As for the other things, I am pretty certain those are anti-features? I don't want the way I find and manage libraries and depenendencies to assume I am going to use some specific build environment, and the entire point of good package management is to be able to reuse packages so encouraging developers to "control how dependencies are built" is asking for trouble.
System-wide package managers give you a single, global version of a package built to interact solely with the rest of that one distribution.
I absolutely do want to control how dependencies are built- I want to build them in debug mode, link them using LTO, cross-compile them, or (Rust-specific, since someone mentioned Cargo) switch the panic strategy. Further, many packages I depend on via language-specific tools likely will never be in any distro's repository, nor should they be.
As for assuming a build environment, that may be an issue with a language like C or C++ that has already gone a different route, but it's better when a language has a single, established way of building things that a package manager can integrate with.
>.. does absolutely nothing to help build your code ..
I don't know much about cargo nor rust. How does it help build your code ? edit: nvm, i found how [0]
>.. manage dependency versions ..
All package managers do. Granted not implicitly when building your source, as you have to install them yourself. Good libraries can have multiple versions installed at the same time (i won't go into nix and such).
>.. control how dependencies are built ..
Most (of the used) programming languages don't need to build dependent libraries, they load them dynamically.
Note that I don't differentiate between code in headers, code in libraries, or even code in other programs that the specific program would communicate with via some IPC. (side note: i have grown fond of single header libraries, for their simplicity)
Also to quote the rust docs "Rust has two distinct terms that relate to the module system: ‘crate’ and ‘module’. A crate is synonymous with a ‘library’ or ‘package’ in other languages."
Not 100% what i was saying, but it does hint on how similar cargo is to a "normal" package manager.
It seems that everyone wants to build in a package manager these days. Rust, racket, haskell, python...
What is wrong with copy-ing code directly ? Do we need these ? It just reminds me of leftpad.
Everyone wants to build a package manager these days because OS-wide package managers don't provide the same feature set that language-specific package managers do.
At the very least (npm, conda) multiple independent environments, allowing conflicting versions of a library to exist simultaneously in different environments. If the language allows it, even in the same environment.
To get that from apt/yum/pacman you need chroots, containers or virtualization.