647291cd6c
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
|
||
|---|---|---|
| config | ||
| corepkgs | ||
| doc/manual | ||
| maintainers | ||
| misc | ||
| mk | ||
| perl | ||
| scripts | ||
| src | ||
| tests | ||
| .dir-locals.el | ||
| .gitignore | ||
| COPYING | ||
| Makefile | ||
| Makefile.config.in | ||
| README.md | ||
| bootstrap.sh | ||
| configure.ac | ||
| local.mk | ||
| nix.spec.in | ||
| release.nix | ||
| shell.nix | ||
| version | ||
README.md
Nix, the purely functional package manager
Nix is a new take on package management that is fairly unique. Because of it's purity aspects, a lot of issues found in traditional package managers don't appear with Nix.
To find out more about the tool, usage and installation instructions, please read the manual, which is available on the Nix website at http://nixos.org/nix/manual.
Contributing
Take a look at the Hacking Section of the manual. It helps you to get started with building Nix from source.
License
Nix is released under the LGPL v2.1
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit.