> It also means that it's impossible to statically know what other packages a given package might depend on. Currently, the way this is implemented is essential

> It also means that it's impossible to statically know what other packages a given package might depend on. Currently, the way this is implemented is essentially grepping a package for /nix/store/ to try to figure out what the dependencies are, which is obviously... not great. That’s not quite how it works. One of the features of the Nix language is that the interpreter associates an invisible “context” with each string to carry dependency information. When you coerce a derivation to a string (in order to use its path in another derivation), the context remembers the build dependency on that derivation. Any derivation built using that string will inherit build dependencies from its context. https://nixos.org/manual/nixpkgs/stable/#function-library-lib.strings.addContextFrom https://nixos.org/manual/nixpkgs/stable/#function-library-li... https://shealevy.com/blog/2018/08/05/understanding-nixs-string-context/ https://shealevy.com/blog/2018/08/05/understanding-nixs-stri... It is true that runtime dependencies are computed by string-searching the build output, but only for paths that have already been determined to be part of the build dependency closure. https://nixos.org/guides/nix-pills/automatic-runtime-dependencies.html https://nixos.org/guides/nix-pills/automatic-runtime-depende... Since store paths have a fixed format with a cryptographic hash, this works plenty well enough in practice—as evidenced by the fact that Nixpkgs exists and has more packages than any other Linux distribution. https://repology.org/repositories/statistics/total https://repology.org/repositories/statistics/total