[Nix-dev] fixed-output derivation that *also* depend on (some of) its inputs?

[Bjørn Forsman]

Hi Shea,

On 1 October 2014 17:59, Shea Levy <shea at shealevy.com> wrote:
> On Wed, Oct 01, 2014 at 10:32:57AM +0200, Bjørn Forsman wrote:
>>
>> Shea, it looks like the deriver (*.drv) doesn't change unless "name"
>> or the output hash attrs changes. So rebuild-if-deriver-changed won't
>> make any difference.
>
> Nope, deriver will change if any attribute changes. Or can you show me
> an example otherwise?

Oh, you're right. It does change. I tested it in nix-repl (perfect
tool for the job!). Earlier today I didn't use nix-repl and must have
messed up when calling nix-build and nix-store -q --deriver.

So yes, a rebuild-if-deriver-changed option would be nice.

>> >> Even though it's a bit hackish, using
>> >>
>> >> stdenv.mkDerivation rec {
>> >>    extraHash = builtins.hashString "sha256" (buildCommand);
>> >>    name = "foo-${extraHash}-0.0";
>> >>
>> >> works just like I want it to.
>>
>> Ouch, it broke real bad when using it in the real world[1]:
>>
>>   fetchGrailsAppDeps = { stdenv, grails, src, sha256 }:
>>     stdenv.mkDerivation rec {
>>       srcHash = builtins.substring 0 20 (builtins.hashString "sha256"
>> (builtins.toString src));
>>       name = "grails-app-deps-${srcHash}";
>>       [SNIP]
>>     };
>>
>> $ nix-build grails-app.nix
>> error: the string `grails-app-deps-b0f29513403e6dca5372' is not
>> allowed to refer to a store path (such as
>> `!out!/nix/store/80bd47sghjl4i41sd783b2w49lqzkm93-git-export.drv'), at
>> /nix/store/rjvnj4skg17is5x9jhzq1yl96mdvch0c-nix-1.7/share/nix/corepkgs/derivation.nix:8:12
>>
>> This only happens when "src = fetchgit { ... }" and not when "src =
>> ./path/to/source". Why?
>>
>
> Use builtins.unsafeDiscardStringContext on the result of toString src
> before hashString.

Thank you very much! Now the world makes sense again.

>> What about a new, optional derivation input like "extraHashInputs = [
>> list of attrs that will be included in calculation of $out ];"?
>>
>>
>> [1]: https://gist.github.com/bjornfor/3f2fda1b1ce077225df5
>>
>
> Please no. This is fixing the problem in the wrong place.

Ok. But a "rebuildIfDeriverChanged = true;" flag then?

Best regards,
Bjørn Forsman