Problem
I'm trying to populate a private cache while leveraging the public cache ("figure out what to build/copy" from an otherwise fresh/empty nix store). This involves a mix of public and private derivations.
My approach involves using nix-eval-jobs --substituters private-cache and inspecting the resulting cacheStatus. If a derivation is notBuilt, then it is not in the private cache.
However, I encountered an issue when the set of things to builds includes a custom Linux kernel:
- IFD (Import From Derivation) in nixpkgs triggers a build against only the private cache.
- IFD appears to be used to compute a kernel config against which assertions are tested during eval.
- This causes excessive rebuilding during the "figure out what to build" step.
- (since the built config is available in the public cache, but not the private one).
This could potentially be worked around by doing two evals; first one with all caches available so that IFD can be resolved, and then a later one to figure out what's not in the private cache. (Aside: This also makes me wonder about the problem how to figure out which paths needed IFD should be copied to the private cache. I suppose this is somewhat resolved (though not exactly efficiently) by doing nix copy --all).
Ideal Behavior
nix-eval-jobs could report which cache a derivation is available in, rather than requiring separate runs with different cache configurations.- This would allow IFD to reference the public cache, reducing unnecessary builds, and make it easy to determine what is absent from the private cache.
- Ideally there would be a way to acquire a list of IFD derivations that were used for the eval so that they can also be copied to a private cache.
Workaround / Request for Input
- Is there an existing workflow solving this problem I've missed?
- Would it be possible to enhance
nix-eval-jobs to expose which cache has the hit?
Related discussion
Pre-RFC: Implement Dependency Retrieval Primitive - this talks quite a bit about the difficulties of IFD. It seems it is assumed most people should avoid IFD, and it is banned from nixpkgs, but I hit a case where it appears in nixpkgs for a custom kernel build, so I need to handle this situation somehow.
Problem
I'm trying to populate a private cache while leveraging the public cache ("figure out what to build/copy" from an otherwise fresh/empty nix store). This involves a mix of public and private derivations.
My approach involves using
nix-eval-jobs --substituters private-cacheand inspecting the resultingcacheStatus. If a derivation isnotBuilt, then it is not in the private cache.However, I encountered an issue when the set of things to builds includes a custom Linux kernel:
This could potentially be worked around by doing two evals; first one with all caches available so that IFD can be resolved, and then a later one to figure out what's not in the private cache. (Aside: This also makes me wonder about the problem how to figure out which paths needed IFD should be copied to the private cache. I suppose this is somewhat resolved (though not exactly efficiently) by doing
nix copy --all).Ideal Behavior
nix-eval-jobscould report which cache a derivation is available in, rather than requiring separate runs with different cache configurations.Workaround / Request for Input
nix-eval-jobsto expose which cache has the hit?Related discussion
Pre-RFC: Implement Dependency Retrieval Primitive - this talks quite a bit about the difficulties of IFD. It seems it is assumed most people should avoid IFD, and it is banned from nixpkgs, but I hit a case where it appears in nixpkgs for a custom kernel build, so I need to handle this situation somehow.