Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Improve the description of how runtime dependencies are found #239

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Improve the description of how runtime dependencies are found #239

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
fea1306
Improve the description of how runtime dependencies are found
noamraph Apr 10, 2024
8a9dd16
Make the description more accurate, and link to the source code
noamraph Apr 12, 2024
91132ba
Fix description: Nix only looks at the hashes of all referenced outputs.
noamraph Apr 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 8 additions & 3 deletions pills/09-automatic-runtime-dependencies.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,11 +46,16 @@ We now note that Nix automatically recognized build dependencies once our `deriv

Nix handles runtime dependencies for us automatically. The technique it uses to do so may seem fragile at first glance, but it works so well that the NixOS operating system is built off of it. The underlying mechanism relies on the hash of the store paths. It proceeds in three steps:

1. Dump the derivation as a NAR. Recall that this is a serialization of the derivation output \-- meaning this works fine whether the output is a single file or a directory.
1. Dump the derivation as a NAR. Recall that this is a serialization of the derivation output — meaning this works fine whether the output is a single file or a directory.

2. For each build dependency `.drv` and its relative out path, search the contents of the NAR for this out path.
2. For each build dependency (including transitive dependencies), search the contents of the NAR for the hash part of its out path. For example:
* Our derivation depends on `/nix/store/sk590g7fv53m3zp0ycnxsc41snc2kdhp-gzip-1.6.drv`
* Its output path is `/nix/store/hcrf95x3r60kw71wgwbdybjfcq0ipkpj-gzip-1.6`.
* Therefore, Nix will search the NAR for `hcrf95x3r60kw71wgwbdybjfcq0ipkpj`.

3. If the path is found, then it's a runtime dependency.
3. Each hash which is found somewhere in the NAR is recorded as a runtime dependency.

(For completeness: some derivations have multiple output paths. In that case, Nix will search for the hashes of all the referenced outputs. Also, Nix will search for the hashes of source dependencies, such as our `build.sh` file. The authoritative definition is the [source code](https://github.com/NixOS/nix/blob/a268c0de7192188c7233bf83a4635198c360e270/src/libstore/build/local-derivation-goal.cc#L2220-L2227).)
Comment on lines +57 to +58
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
(For completeness: some derivations have multiple output paths. In that case, Nix will search for the hashes of all the referenced outputs. Also, Nix will search for the hashes of source dependencies, such as our `build.sh` file. The authoritative definition is the [source code](https://github.com/NixOS/nix/blob/a268c0de7192188c7233bf83a4635198c360e270/src/libstore/build/local-derivation-goal.cc#L2220-L2227).)

let's skip this for now I think but do the rest:

Basically, I don't think the inputSrcs vs inputDrvs distinction is very useful for the user. From the user's perspective I think it is better to think that the inputs are just the closure of some set of store objects, and those store objects are specified either directly by store path, or by (drv path, output name) pair.

Also I rather not link to source code, as stuff gets moved around fairly frequently. (Yes, there is a commit hash in there, but old code can also be misleading.) Hopefully this stuff gets some proper reference docs soon, and then the the nix pills can link it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally prefer to leave this paragraph. If someone isn't interested in the details, it's very easy to skip, as it's between parentheses and starts with "for completeness". However, for me it feels better to feel that I better understand the details of this "magic". I think that specifically mentioning source inputs in addition to derivation inputs has value, since the description about taking the output of a derivation doesn't apply for those inputs.

Regarding the link to the source code, I agree it's not ideal, but until there is a proper reference, I think that it's better than nothing. When there is a proper reference, we should obviously link to it instead of the source. Do you think it will be better if we make it clearer that you should check the current sources and not what's in the actual link? For example, we can have:

The authoritative definition is the source code; you can start from here and check what's changed since the time of writing.

Also, reading it again, if we decide to leave this paragraph, I think I would make the description clearer. Instead of:

Also, Nix will search for the hashes of source dependencies, such as our build.sh file.

Write:

Also, in addition to dependencies which are derivations, there are source dependencies, such as our build.sh file. Nix will also search for the hashes of those, and if found, will add them as runtime dependencies.


The snippet below shows the dependencies for `hello`.

Expand Down
Loading