You completely misunderstand the point. "Another package manager" doesn't matter. People can and should use the package manager of their choice (why should I break pip?). The point is to have common ground between all package managers.
Could you talk about the advantage(s) you perceive of a "common ground between all package managers"? After using npm a bit I think scripting hooks in a package manager that can call other package managers enables many good things.
Well, for one thing, new package managers could be implemented without having to worry about the infrastructure. The server software could be shared between all linux distributions and would be applicable for any sort of "bundle server"; think game addons, firefox/chrome extensions, skins for your favourite software and what not.
One is that you can easily specify dependencies on packages not written in the language your package is written in, in a way that's machine-readable. Imagine if I could do "npm install some-framework" and it'd automatically build and install the relevant versions of node.js and MongoDB as well.
This way I never need a global install of bower, nor do I ever really need to use it directly. I don't see why something similar couldn't be set up for any other npm-able package manager or build tool. A bit of googling seems to indicate that npm can update node using e.g. the "n" module. That module or another like it can of course be a dependency in package.json.
This isn't machine-readable, for a start - I can't see what your package actually depends on without reading through your postinstall script. I also can't write a script to convert it automatically to a .deb or a NixOS package or whatever else, because I can't figure out what its dependencies are. I can't easily say "I want this package and all its dependencies on a DVD".
The dependency on bower is stated explicitly. The dependencies that bower manages itself are easily discoverable in bower.json. I don't see why a call to bower is any more of a problem than any other build step, e.g. make.
I get that having a standard format (let's say "dependencies", "devDependencies", and "peerDependencies" as properties of a json file) would make somebody's life easier, but it's not clear that is the same set of somebodies who develop and use all these package managers.
> I don't see why a call to bower is any more of a problem than any other build step, e.g. make.
Because dependency management is a separate problem from building. I need to be able to see what, exactly, every package depends on, and to be able to operate on that, to be able to deploy my system, and in order to know what exactly it is that I'm running.
Figuring out what my dependencies are at the same time as building my system leads to near-constant breakage, and I couldn't even figure out "am I using this package somewhere or not?" because there's no central package database when using npm/pypi/whatever else. How am I supposed to figure out whether my system is secure if I can't figure out what's installed on it to match against the CVE databases?
Today, I solve this with an extremely hackish set of scripts (npm2nix, pypi2nix, etc) and a lot of manual overrides to specify dependencies between bits of code written in different languages, and wrap that into one package database. Operating system distributors are forced to do the same.
> I get that having a standard format (let's say "dependencies", "devDependencies", and "peerDependencies" as properties of a json file) would make somebody's life easier, but it's not clear that is the same set of somebodies who develop and use all these package managers.
As a user of package managers, it would make my life easier if everybody would actually define all their dependencies in such a way that I can run an automated tool against a list of packages and discover every single package, so that I can wrap them into a DVD for offline installation, or figure out whether I'm vulnerable to something, or convert them for use with my own package manager, or whatever else I want to do.
