<catern>
Say we want to keep builds in the Nix store completely pure.
<catern>
We aren't doing so good right now on that in any case, because fixed-output derivations have various impure escape hatches: impureEnvVars, network access, etc
<catern>
But say we wanted to start making sure that after a Nix expresion is instantiated as a low-level derivation, it's totally pure
<catern>
Well then, we need to do the impure things at Nix evaluation time. Which means we need to intermix instantiating-and-pure-building with evaluating-and-impure-building. a lot like with IFD?
<catern>
I actually think that might be fine, and if we did that it would make it trivially easy to solve that issue/my problem...
<catern>
so anyway, this is yet another motivation for embracing mixing evaluation and building...
<catern>
any immediate thoughts?
<simpson>
catern: I understand your desire and don't have any good ideas.
<gchristensen>
an immediate thought is I count on evaluation not performing builds in the ofborg project
<catern>
well, okay, this isn't completely like IFD, because actual evaluation doesn't require building. maybe you'd only want to do the impure building at *instantiation* time?
<catern>
then you can evaluate without doing impure things?
<catern>
impure builds*
<catern>
actually, I guess I don't understand why instantiation is necessary at all... let me take it to #nixos
<gchristensen>
well I guess I didn't realize they were different things
WilliButz has quit [Ping timeout: 276 seconds]
WilliButz has joined #nixos-dev
<catern>
okay so this might not be how it actually works currently, but
<catern>
but, I think, instantiation evaluates *all* the attributes in all the derivations in the tree of dependencies. and I guess ofborg just looks at certain attributes of all the derivations in the tree of dependencies?
<catern>
in the presence of IFD in an expression returning a derivation, both of those will cause builds to need to be run, just so you can look at *any* attribute of the derivation
<catern>
in the presence of an "impure derivation" (which could be a fixed-output derivation which holds an attribute which, when it is forcibly evaluated by instantiation, performs the actual build outside the store using hacky impure primops) you can look at any of the usual attributes, and the inputs, just fine
<catern>
as long as ofborg just looks at a few attributes, and doesn't need to know the store path of the derivations, then it would be fine
<gchristensen>
offborg looks at all of the attributes and looks at all of the store paths
<gchristensen>
this is how the rebuild count is estimatede
<catern>
hmm, awkard :)
<catern>
yeah okay this seems like a nightmare
<catern>
I'm just going to, eh... make a class ImpureFixoutStore, which inherits from Store, and which holds a real Store, and which mostly just proxies to the real store, except for building fixed output derivations, which it does by forking off a builder from the current process
<catern>
or maybe it should be a method on Store itself
<catern>
(a non-virtual method)
ma27 has quit [Ping timeout: 255 seconds]
<catern>
hmm, okay, reading some more of the Worker and Goal stuff inside Nix, I kind of hate it :)
<catern>
I'm tempted to instead write my own independent implementation of the nix-daemon remote store API