How does Nix compute runtime dependencies for commands like nix-copy-closure and nix copy?
Reading the Nix Manual, it appears to say that runtime dependencies are computed when needed, by scanning output paths for other /nix/store/* paths.
I have a couple questions about this:
Is the above explanation correct? This information is computed on-the-fly, and not present in the .drv file, correct? Can anyone point out the place in the Nix source code where this scanning step takes place?
There are a couple commands I know of to let you easily inspect the runtime (or build-time) closure:
I suggest reading the nix-pills which explain exactly these kinds of detail. If you still have questions after reading them, I suggest asking again in this discourse: I think that one question per thread would be easier to answer.
You kind of answered this yourself. As long a nix can read a /nix/store path in the outputs, it will consider it a runtime dependency. Nix can’t know about these paths til after it builds a package, so this is why why-depends will usually build the package before giving output.
The out paths from the inputs is known, and nix can assert that the paths exist.
It would probably be located in the nix store realize code, but I’m not super familiar with the code base.
nix-store --query --references for direct runtime dependencies nix-store --query --requisites for all runtime dependencies
if you pass a .drv, you will get the related build dependencies.
nix why-depends and grep are all that I’m aware of.
You can use disallowedReferences or disallowedRequisites when creating your derivation to prevent this Introduction
As long as the store path appears in the out path, it will be a runtime dependency.
$ sqlite3 /nix/var/nix/db/db.sqlite
sqlite> select id from ValidPaths where path = "/nix/store/jr56bx8a41h1x0wm7ih2mic5i3cjfcm1-coreutils-8.32";
sqlite> select path from ValidPaths where id in (select reference from Refs where referrer = 48929);
These look like they could be really helpful when actually writing derivations. I’d mainly image using them as debugging tools.
This is a great example. It is very simple and shows exactly what is going on. It makes sense that the .jar files are compressed, so the /nix/store/* paths inside them need to explicitly added in a nix-support file.
@danieldk Ah, I didn’t realize that this information is stored in the Nix DB.
I had assumed this information was computed at runtime when needed by commands like nix copy and nix-copy-closure.
However, given that there are special attributes like disallowedReferences that can be used from within Nix, I guess runtime dependencies are calculated after a derivation is built and preemptively stored in the Nix DB (as opposed to be computed lazily when needed).
I’m still interested in reading the actual Nix code that scans files and computes runtime dependencies if anyone knows where to find it in the Nix codebase.