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.
At the very least (npm, conda) multiple independent environments, allowing conflicting versions of a library to exist simultaneously in different environments.
One should never, ever bypass the operating system's software management subsystem, because then, one needs a hack like Docker, since the OS will have no notion of the software installed, and a system specifically invented and designed for managing said software won't be able to manage it. I could author a book on just how bad of an idea using a packaging system proprietary to some language or application is. By utilizing a packaging system outside of the operating system's packaging, anyone doing so undermines operational repeatability (see capability maturity model level 2 and higher).
allowing conflicting versions of a library to exist simultaneously in different environments.
That's another very bad thing: it's a workaround for lack of thinking about backwards compatibility, and designing a single library with multiple versions of the API, and, and, and... I happen to work on an application which utilizes 300 such environments, and it's a nightmare.
Finally, by using a packaging system proprietary to a language, anyone doing so is now forcing everyone else who wants to use said software to wrestle with multiple packaging systems; and if every developer thought that way, the end consumer would have to wrestle with all of them. I don't think I need to point out just how irresponsible, not to mention inconsiderate that is towards users. Users of the application, not developers should come first, and only then everything else. In this day and age of automated builds, it is trivial to set up automatic generation of operating system packages for various systems. Trivial, and developers must take responsibility for that, instead of putting the onus on the consumer of the software.