[_pmf_]

> Someone please work on this.

The only result will inevitably be that we'll have yet another package manager.

[scrollaway]

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.

[jessaustin]

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.

[scrollaway]

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.

[vertex-four]

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.

[jessaustin]

This is what I meant by "scripting hooks". I have something like the following in package.json for various projects:

  "devDependencies": {
    "bower": ">=1.3"
  },
  "scripts": {
    "postinstall": "bower install"
  }

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.

[vertex-four]

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".

[jessaustin]

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.