-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Add --include-build-refs to `nix path-info' command #3523
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.
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
Conversation
This allows use you to get all drvs that your Nix expression references. Output looks like this: $ nix-instantiate --include-ifd warning: you did not specify '--add-root'; the result might be removed by the garbage collector /nix/store/xvplw4i56ys3j1lk4bxnr8r4725rb6c8-bauer-1.5.0.drv /nix/store/nk7j41ldlq39lmmsg5v1mlwwwpnqnbgk-README.drv /nix/store/pp84r1z7j7aqqarbwkq55h5asy35rs15-package-list.drv This can be piped put into nix-store to get all outputs needed: $ nix-store -qR --include-outputs $(nix-instantiate --include-ifd) /nix/store/00crwk6z71l36av0gspzi0z410h8fq1r-libXtst-1.2.3.tar.bz2 /nix/store/9krlzvny65gdc8s7kpb6lkx8cd02c25b-default-builder.sh /nix/store/58y89v7rl254dc2cygcfd5wzhv0kjm4m-bash44-013.drv /nix/store/7c0yirypq720qgj2clyanqp3b18h1lj0-bison-3.4.2.tar.gz.drv /nix/store/b7irlwi2wjlx5aj1dghx4c8k3ax6m56q-busybox.drv /nix/store/c0sr4qdy8halrdrh5dpm7hj05c6hyssa-unpack-bootstrap-tools.sh /nix/store/drsdq2ca1q1dj1hd0r1w2hl4s0fak1vh-bootstrap-tools.tar.xz.drv /nix/store/bfil786fxmnjcwc7mqpm0mk4xnm2cphg-bootstrap-tools.drv ...
This print out all of the store paths referenced in the Nix expression. Examples provided in --help. This is useful with tools like cachix, and replace the previous usages of: $ nix-store -qR --include-outputs $(nix-instantiate '<nixpkgs>' -A hello) which now become: $ nix refs --build --run nixpkgs.hello which can be piped into cachix like: $ nix refs --build --run nixpkgs.hello | cachix push my-cache Related to cachix/cachix#52 and NixOS#3506
nix-instantiate is deprecated!
Maybe these could be flags to |
That might make sense, but right now For build-time dependencies, we actually could use the "deriver" field to get that derivation, but it's frequently missing. Also eval-time will always need an expression (unless we add something like a "deriver-expression" field) |
Perhaps we could rename it to |
Maybe call it `nix info` and make it take both expressions and nix store
paths?
…On Wed, 22 Apr 2020 at 21:44, Matthew Bauer ***@***.***> wrote:
Perhaps we could rename it to nix expr-info?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3523 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAIDIO5LEEWKIMAEEVBNF3RN5CJTANCNFSM4MNYQ6VA>
.
|
|
Both require --recursive. --build calculates all buildtime dependencies of a path. --eval calculates all evaltime dependencies of an expression.
Updated to use |
Now used in nix/command.cc error
@edolstra Let me know if any concerns remain. It should be ready for re-review. |
If we still have the .drv, it will be available in our database under deriver. We can use that instead of requiring we actually received a drvPath.
Updated to support |
Co-authored-by: John Ericson <git@JohnEricson.me>
Hmm i actually think |
Even non-derivations are important to have in this output, so keep them in our list.
This is more accurate since things like fileExists and readFile also go through this.
Runtime deps aren’t always useful, especially in the case of creating gc roots for eval deps. for instance: $ nix-store --add-result --indirect -r $(nix path-info --recursive --no-run --eval my-expression)
src/libexpr/primops.cc
Outdated
@@ -54,6 +54,7 @@ void EvalState::realiseContext(const PathSet & context) | |||
auto ctx = store->parseStorePath(decoded.first); | |||
if (!store->isValidPath(ctx)) | |||
throw InvalidPathError(store->printStorePath(ctx)); | |||
importedPaths.push_back(ctx.clone()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we would want to push the path to the specific output rather than drv file in this case? for --build --eval
would we get the original drv file again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be useful to have more information, but this is all that's needed for the computeFSClosure. The original drv needs to be included to get dependencies for --build
. It may end up getting in multiple times, but I think that's okay.
From counting the number included, I am fairly sure it is the right thing. For instance, here's the deps I get for each:
recursive | evaltime | buildtime | runtime | total |
---|---|---|---|---|
Y | N | N | N | 0 |
Y | Y | N | N | 218 |
Y | N | N | Y | 293 |
Y | Y | N | N | 511 |
Y | N | Y | X | 1003 |
Y | Y | Y | X | 1008 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What standard commands or flags would enumerate all of these, but it can be unclear how to get a report/listing of each row. How was this generated?
Does anyone have objections to the naming of the options here? |
I'm hesitant about adding these flags:
|
|
This could have some bad interactions with the eval cache. Once flakes is merged, we can resolve those so that --eval will always reevaluate the expression.
Updated to just provide |
@edolstra there's no way to do this currently with flakes, which really limits ways to inspect closures for build dependencies. If we stop materializing to disk, we can still compute the build closure it just can't be cached? |
Can |
@domenkozar @edolstra Any chance this can get some more review? I've updated on to master and now renamed it to --include-build-refs. I'm hoping the longer, more specific name means it's a little less objectionable and more obvious how it fits into the --recursive flag flow. |
fcf4fe6
to
86b65fc
Compare
Continuation of NixOS#3523, but with evaluation-time refs this time. More discussion is available at that PR. This keeps track of imported paths when evaluating. When --recursive & --include-eval-refs is passed, these paths & their references are included in the resulting closure.
@matthewbauer does it address concerns raised by @edolstra? I'm +1 for merging it otherwise. |
This primop lets you get information on paths realised (pathExists, import, readFile) by Nix. It tracks paths realised in Nix & puts the results under the "paths" attr. For instance: $ nix eval --impure --expr '(builtins.traceContext (import ./.).outPath)' { paths = [ "/nix/store/2mpgi4bvn8py4liv9w3mjxd2c5r7bvv8-source" "/nix/store/3k7i1rdqcgyzjxvqm37hapdidy4ls4s3-source" "/nix/store/kqxic0j6wpsaw2bb51hr1yc1nb1z2xw8-source" ]; value = "/nix/store/3k7i1rdqcgyzjxvqm37hapdidy4ls4s3-source"; } This is an alternative to the --include-eval-refs from NixOS#3523 & --include-ifd from NixOS#3506.
This print out all of the store paths referenced in the Nix
expression.
This is useful with tools like cachix, and replace the previous usages
of:
which now become:
which can be piped into cachix like:
It provides a flag for
--include-build-refs
, meant to parallel dependencies needed fornix build
.Related to cachix/cachix#52
and #3506
/cc @domenkozar @edolstra