Impure derivations are derivations that can produce a different result
every time they're built. Example:
stdenv.mkDerivation {
name = "impure";
__impure = true; # marks this derivation as impure
buildCommand = "date > $out";
};
Some important characteristics:
* Impure derivations are not "cached". Thus, running "nix-build" on
the example above multiple times will cause a rebuild every time. In
the future, we could implement some mechanism for reusing impure
builds across invocations.
* The outputs of impure derivations are moved to a content-addressed
location after the build (i.e., the resulting store path will
correspond to the hash of the contents of the path). This way,
multiple builds of the same impure derivation do not collide.
* Because of content-addressability, the output paths of an impure
derivation recorded in its .drv file are "virtual" placeholders for
the actual outputs which are not known in advance. This also means
that "nix-store -q bla.drv" gives a meaningless path.
* Pure derivations are not allowed to depend on impure
derivations. The only exception is fixed-output derivations. Because
the latter always produce a known output, they can depend on impure
shenanigans just fine. Also, repeatedly running "nix-build" on such
a fixed-output derivation will *not* cause a rebuild of the impure
dependency. After all, if the fixed output exists, its dependencies
are no longer relevant. Thus, fixed-output derivations form an
"impurity barrier" in the dependency graph.
* When sandboxing is enabled, impure derivations can access the
network in the same way as fixed-output derivations. In relaxed
sandboxing mode, they can access the local filesystem.
* Currently, the output of an impure derivation must have no
references. This is because the content-addressing scheme must be
extended to handle references, in particular self-references (as
described in the ASE-2005 paper.)
* Currently, impure derivations can only have a single output. No real
reason for this.
* "nix-build" on an impure derivation currently creates a result
symlink to the incorrect, virtual output.
A motivating example is the problem of using "fetchurl" on a
dynamically generated tarball whose contents are deterministic, but
where the tarball does not have a canonical form. Previously, this
required "fetchurl" to do the unpacking in the same
derivation. (That's what "fetchzip" does.) But now we can say:
tarball = stdenv.mkDerivation {
__impure = true;
name = "tarball";
buildInputs = [ curl ];
buildCommand =
"curl --fail -Lk c1f89c077e > $out";
};
unpacked = stdenv.mkDerivation {
name = "unpacked";
outputHashAlgo = "sha256";
outputHashMode = "recursive";
outputHash = "1jl8n1n36w63wffkm56slcfa7vj9fxkv4ax0fr0mcfah55qj5l8s";
buildCommand =
"mkdir $out; tar xvf ${tarball} -C $out";
};
I needed this because <nix/fetchurl.nix> does not support unpacking,
and adding untar/unzip functionality would be annoying (especially
since we can't just call "tar" or "unzip" in a sandbox).
https://github.com/NixOS/nix/issues/520
2017-02-24 19:36:26 +01:00
3 changed files with 102 additions and 30 deletions
Eelco Dolstra