>Also, the problem with npm/pip etc is that they are themselves package managers more or less trying to solve the same thing. The problem is that they're tryin

>Also, the problem with npm/pip etc is that they are themselves package managers more or less trying to solve the same thing. The problem is that they're trying to solve different problems. NPM/pip etc are mostly about letting the developer of an internal application choose and acquire dependencies for their project. Nixpkgs/dpkg etc are about letting the developers of a system acquire and maintain dependencies for a whole system. These two goals pull in different directions. NPM/pip want to have available every released version of every package, so that when I can keep using legacy-package with a well-tested version of web-dependency. This way, I can focus my attention on the important matters of writing new code for contemporary-project. I can be confident that legacy-package will keep running the same way it used to, security bugs and all, until I make a decision to attend to it. Nixpkgs/dpkg want to have available as many packages as possible with a target that every api incompatible library is included, so that any two programs which use the same api use the same version of a package. This way, if they need to patch a well-tested but insecure version of web-dependency, all programs which use it will be kept up-to-date. Because nix is an agnostic build tool, it can run in both modes simultaneously. You can create a nix expression that uses nixpkgs to build a system that provides a runtime environment and a system that provides a buildtime environment and then uses internal project dependency managers to fulfil the lockfile and installs the product of that, node_modules and all, onto the runtime system. You will lose certain guarantees by doing it this way, and perhaps some parts will require awkward, but that is an engineering decision. For instance, nix won't be able to verify that you aren't depending on changeable remote systems, because you'll have chosen to do that: Nix doesn't trust that npm is add-only, but you might. (Also, some aspects of this will be poorly documented. That's a fixable problem, but the maintainers of a package distribution are probably less interested in the case that optimises for concerns they've chosen not to optimise for, so the documentation for working that way will naturally be worse.)