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

[Wout Mertens]

Isn't the whole point of the fixed-output derivations that the means of
getting there doesn't matter? So if you change the build script but leave
the output hash the same, you're basically saying that the build script
will generate the same output.

I think what you want is to remove a build product from the store when you
change the build scripts?

As for this use case, handbrake also downloads a bunch of things as part of
the build and I made the expression just patch that away, moving all the
extra building and patches into other expressions.

Another approach might be to use recursive Nix (building new nix
expressions as part of a nix build), although I'm not sure what the state
of that is.

Wout.

On Sun, Sep 21, 2014 at 6:37 PM, Bjørn Forsman <bjorn.forsman at gmail.com>
wrote:

> On 21 September 2014 08:15, Vladimír Čunát <vcunat at gmail.com> wrote:
> > On 09/20/2014 09:55 PM, Bjørn Forsman wrote:
> >>
> >> Since fetchurl (via the nixos tarball mirror) downloads the same old
> >> file (even though it creates a new store path), the result outputHash
> >> is the same as before. So evaluation doesn't stop but continues on
> >> with old/wrong data.
> >
> >
> > If fetchurl *did* download any other data, then it would fail while
> checking
> > the hash. That was my point. Nixos tarball mirror may be different and
> > download the same content, but in any case that doesn't change the plain
> > fact of the first sentence of this paragraph.
> >
> > I think we all agree on how fetchurl works, but I still have no idea what
> > you desire. I may be an exception, but I don't see what could be done
> > "between" the current fixed-output and standard derivations. Either you
> do
> > know what exactly the output should look like and then it doesn't really
> > matter how you arrive at it, or you don't know it and then you have a
> > standard derivation.
>
> I'll try to explain the issue with an example. Given the following
> expression:
>
>
> with (import <nixpkgs> { });
>
> stdenv.mkDerivation rec {
>   name = "foo-0.0";
>
>   outputHashAlgo = "sha256";
>   outputHash = "0sldaa6dd6dsfm1c7f8z9i32dfhn53aw1kyrlid1naa7hb6biy4v";
>   outputHashMode = "recursive";
>
>   buildCommand = ''
>     mkdir -p "$out"
>     echo hello >"$out/file"
>   '';
> }
>
>
> Build it. Then change the "echo hello >$out/file" to "echo foobar
> >$out/file". The output will clearly change, but nix has cached the
> result and will not do a rebuild. That's bad!
>
> (You may at this point wonder, why use fixed-output derivation at all?
> It's because the buildCommand, as is the case when packaging grails
> apps, will download dependencies from the internet, so a standard
> derivation will fail.)
>
> I can work around this "caching" this by adding some hackery:
>
> stdenv.mkDerivation rec {
>   extraHash = builtins.hashString "sha256" (buildCommand);
>   name = "foo-${extraHash}-0.0";
>
> This results in a derivation that gets rebuilt/checked whenever
> buildCommand changes. This is what I want.
>
> But this solution feels very hackish. So my question is whether it's
> possible to tell nix that certain derivation inputs affect the output,
> so that when the inputs change, nix has to rebuild / re-check the
> result.
>
> It seems that when using fixed-output derivations, only the "name"
> attribute matters. I think there are use cases (like the example
> above) that requires other derivation inputs to be considered
> important enough to do a rebuild.
>
> Vladimir, does it make sense to you now?
>
> Best regards,
> Bjørn Forsman
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140922/68da34ca/attachment.html