Improved evaluation times with pre-resolved Nix store paths
26 comments
·February 12, 2025jljljl
jkarni
We also do something similar at garnix, but when enabling incremental builds. Instead of just skipping the build stage, we also “normalize” the eval into just the store path, and skipping it the second time around.
Mentioned in passing in https://garnix.io/blog/incremental-builds. This is even more significant because in this case you might otherwise be eval-ing several layers of flakes.
biggestlou
Blog post author here! Please feel free to ask me any questions directly in this forum :)
mongol
Can the evaluation tax be quantified in some way? In other words, how big is the problem that this solves?
biggestlou
Unfortunately, it's really hard to generalize. If the evaluation involves Nixpkgs, for example, Nix needs to copy Nixpkgs into the Nix store, which is many MB. And of course this needs to happen for all flake inputs. I've seen this evaluation take a few seconds and I've seen it take several minutes, but in general the more flake inputs the longer you can expect it to take.
grhmc
(DetSys Cofounder here) I've had Raspberry Pi's give up their last ghostly breath evaluating NixOS.
null
mongol
This will make discourse.nixos.org explode again. It happens every time Determinate System publishes something.
_huayra_
The unusually high amount of drama in NixOS is one of the reasons I have been hesitant to start using it. Jon Ringer (a former contributor) posted a giant video [0] outlining his history with the project and how he left / was forced out (amongst several other key folks). For the record, I don't know how to characterize his exit, only that there was an absolute ton of drama around it that wasn't really related to even any technical aspect.
mongol
Listened to this video yesterday and it just makes me sad. In my opinion, Jon has been let down by the community to which he belonged. It is clear there were differences of opinion and so on, but I did not see anything that motivated his expulsion permanently. It left an especially bad taste that it was on recommendation by the Constitutional Assembly. Their mission was to propose a constitution, not to act as arbiter in moderation matters.
asmor
I don't agree with Jon on a personal level, but who was technically in the right aside, he also made some choices that'd accelerate your exit from any organization or community during the events.
Let's just say his approach wasn't one of reconciliation and de-escalation.
knoopx
what a coincidence, my eval times have worsened over the past months too!
asmor
DetSys, once again, building a moat.
I really do not like how this approach depends on their seemingly not open source backend. Nix needs tools like this, no question, but I'd hate to see it get adoption through a way that isn't reproducible by anyone. It looks like it could be a repeat of the Snap store problem - interesting tech, made unusable through de-facto dependencies on proprietary services.
larusso
I didn‘t look too deep into Nix the last couple of months (> 12) and was wondering while reading: what the hell is fh now. Another abstraction? I share your views here!
biggestlou
fh is the CLI tool for FlakeHub. It's been around almost as long as FlakeHub itself. It's pretty standard fare, not really an abstraction per se.
rounce
‘Standard’ if you live in the flakehub ecosystem, which the vast majority of Nix users don’t.
biggestlou
Out of curiosity, do you object to the existence of services like Cachix, Nixbuild, and Garnix, which also do not have open source backends?
asmor
If their founder was the person with principal control over what goes into CppNix, yes.
biggestlou
Is there a Nix-based company co-founded by Eelco Dolstra to which you wouldn't object?
mongol
Is it really a moat though? The same flake can still be evaluated without this service, it just takes longer.
asmor
And I can still install a snap on an Ubuntu Core machine by building my own distribution method, but it will be a downgrade from the experience of running "snap install something" that introduced me to it. So nobody does.
Lix (yes, I will mention it again) essentially exists by a large degree because the overlap between the people that control Nix and DetSys is big, even very big if you look at CppNix.
mongol
I don't follow this argument. Unless you chose to step in to DetSys ecosystem with this fh tool or whatever, this has no impact on you at all.
This is cool! We do something similar in Devbox where we pre-evaluate store paths from the Nix repository, and then fetch the packages directly from the official Nix cache. This greatly reduces the evaluation time.
Here's a blog post we wrote on the topic:
https://www.jetify.com/blog/how-we-sped-up-nix-package-insta...