Allow non-CA derivations to depend on CA ones#4056
Conversation
| case DerivationType::DeferredInputAddressed: | ||
| break; |
There was a problem hiding this comment.
I think we need to set hasUnknownHash = true here or something so that DeferredInputAddressed cascades to downstream input-addressed derivations?
There was a problem hiding this comment.
I'm not sure. The reasoning behind the current code is that that way we can call hashDerivationModulo on a derivation that's advertising as DeferredIA but actually has a statically known hash. It's used in rewriteDerivation to convert the DeferredIA into an IA.
And if the derivation is indeed Deferred, then at least one recursive call to hashDerivationModulo will return UnknownHash{} so we'll get the same result
There was a problem hiding this comment.
Ah OK. That makes total sense. Then I'd say just one thing we might do is add a flag to hashDerivationModulo about whether it should try to un-defer DeferredIA derivations: in build.cc it definitely should (just like it does now), but I think in primops.cc it shouldn't because that be impure, leaking what derivations we've already built and which CAs we got from them, into eval itself.
There was a problem hiding this comment.
that be impure, leaking what derivations we've already built and which CAs we got from them, into eval itself.
I don't think it does, hashDerivationModulo only looks at the derivations themselves. So if we depend on a floating-ca derivation it will always return UnknownHash{}, regardless of whether it has been built or not. The reason why we have a different return in build.cc is that we call it on the resolved derivation which is still marked as Deferred (because we haven't rebuilt its inputs yet) but doesn't depend on any floating-ca derivation anymore.
There was a problem hiding this comment.
Ah right, and it's only drvPathResolutions that we insert into by hand in build.cc, whereas drvHashes is just manually inserted into in primops.cc, where as you say there is nothing intrinsically impure going on. Sorry for the noise then! It's tricky but ends up working out great :).
(I'm not sure why, but it's not showing me the button to resolve the thread I started. I would if I could!)
There was a problem hiding this comment.
Wait, one thing is that input-addressed derivations conventionally keep their their input-addressed input drvs. But if we rewrite then hashDerivationModulo, they won't have any input drvs, even if those input drvs were input-addressed.
This isn't too bad, in fact this is how we "wish" input-addressed derivations worked all along, but it does mean that if one replaced a fixed output derivation with a floating CA derivation that produces the same outputs, one will get a different input-addressed path.
| }; | ||
| rootCA = mkDerivation { | ||
| name = "dependent"; | ||
| name = "rootCA"; |
| Hash, // regular DRV normalized hash | ||
| CaOutputHashes | ||
| CaOutputHashes, // Fixed-output derivation hashes | ||
| UnknownHashes // Deferred hashes for floating outputs drvs and their dependencies |
There was a problem hiding this comment.
Is it safe to put UnknownHashes in the memo table? I long though it wasn't but I think since deferred derivations look different it, it is!
|
Please rebase now that #3958 is merged, it will make it a bit more convenient to review. |
|
(rebasing is fine, but it should be enough merely to do something that will get GitHub to recompute the diff, such as pushing any new commit or even just setting the PR target branch to something else and then setting it back.) |
c3696f7 to
48b33f3
Compare
|
I've just rebased on top of master, should make the diff smaller |
|
I've just added a test case to ensure that non-ca derivations that depend on a CA one are properly cached (this is kind-of obvious given the flow of the code, but I think it's worth testing if only to prove that it actually works) |
Although the non-resolved derivation will never get a cache-hit (it doesn't have an output path to query the cache for anyways), we might get one on the resolved derivation.
f57ebd0 to
ab21ab6
Compare
|
Well there was the thread up to #4056 (comment) with a smidgen of controversy, but that's just something for you to be aware of @edolstra. I'm with this for now; and we can either change that later or just not care. |
| [&](DerivationOutputCAFloating dof) { | ||
| return newInfoFromCA(dof); | ||
| }, | ||
| [&](DerivationOutputDeferred) { |
…sed ones Fix an overlook of NixOS#4056
…sed ones Fix an overlook of NixOS#4056
Builds on top of #3958
There's a few things that I'm not really happy with wrt. the clarity of the code, but it would require a bit of refactoring so I'll probably address that in a subsequent PR in order not to delay this one