evaluated: introduce nixpkgs package list evaluation as a package #357934
Conversation
Signed-off-by: lucasew <[email protected]>
lucasew
force-pushed
the
20241119-eval-as-a-package
branch
from
e57b20f to
b2c82a4
Compare
|
|
What's the motivation to have this in nixpkgs? |
It's more like an experiment to allow parallelization of nixpkgs evaluation for ofborg, nixpkgs-review and stuff like that. It's kinda slow tho, like almost 10 minutes for a full nixpkgs evaluation but the data is nice! |
ofborg
bot
added
8.has: package (new)
| else if !evaluated.success then | ||
| builtins.trace ":tree: exception ${pathStr} :tree:" null | ||
| else if isDerivation tree then | ||
| builtins.trace (builtins.unsafeDiscardStringContext ":tree: derivation ${pathStr} ${tree.drvPath} :tree:") null |
There was a problem hiding this comment.
How does it compare to the existing approach using nix-env. That one seems to be faster in our current CI than the 10 minutes that you are describing?
There was a problem hiding this comment.
This is what we also do in nixpkgs-review.
There was a problem hiding this comment.
In this case we can also diff added functions, not only derivations
IDK exactly how nix-env traverses packages so I don't know the differences in approach
There was a problem hiding this comment.
What would we do with the function diff? We cannot test those directly, can we? Should be added function not also obvious from reading the diff?
There was a problem hiding this comment.
Here is what is currently done:
Line 86 in 9bd1d56
There was a problem hiding this comment.
What would we do with the function diff? We cannot test those directly, can we? Should be added function not also obvious from reading the diff?
Can't test, yet, but it shows in the diff when another function is introduced. Maybe when we introduce some kind of passthru.tests for functions we could automate testing only the functions that changed and it's dependents.
BTW my intention here is to experiment with a different approach, like how faster or slower can we go if we builtins.trace the stuff instead of returning a data structure using nix-env, and running it on a derivation so it could be offloaded to a remote builder.
Maybe the implementation could be faster but I don't know how to optimize further.
There was a problem hiding this comment.
Sure. I just wanted to summarize of how things work today. I also did some experimenting in the past with walking the tree with nix, but wasn't able to beat the C++ function that nix-env uses internally back than. Also this new github eval goes in a similar direction.
This is a package that basically takes a nixpkgs tree and evaluates the package, and function, list to a file so comparing different releases is faster.
It runs as a nix derivation so the expensive evaluation could be offloaded to a worker node.
It returns a text file with the item path from pkgs, the type and the outPath if it's a derivation.
Implementation may be suboptimal but suggestions are welcome.
Consider this a experiment.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.