-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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 https://github.com/NixOS/patchelf/tarball/c1f89c077e44a495c62ed0dcfaeca21510df93ef > $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). #520
- Loading branch information
Showing
3 changed files
with
98 additions
and
21 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters