* Formalise the notion of fixed-output derivations, i.e., derivations
for which a cryptographic hash of the output is known in advance.
Changes to such derivations should not propagate upwards through the
dependency graph. Previously this was done by specifying the hash
component of the output path through the `id' attribute, but this is
insecure since you can lie about it (i.e., you can specify any hash
and then produce a completely different output). Now the
responsibility for checking the output is moved from the builder to
Nix itself.
A fixed-output derivation can be created by specifying the
`outputHash' and `outputHashAlgo' attributes, the latter taking
values `md5', `sha1', and `sha256', and the former specifying the
actual hash in hexadecimal or in base-32 (auto-detected by looking
at the length of the attribute value). MD5 is included for
compatibility but should be considered deprecated.
* Removed the `drvPath' pseudo-attribute in derivation results. It's
no longer necessary.
* Cleaned up the support for multiple output paths in derivation store
expressions. Each output now has a unique identifier (e.g., `out',
`devel', `docs'). Previously there was no way to tell output paths
apart at the store expression level.
* `nix-hash' now has a flag `--base32' to specify that the hash should
be printed in base-32 notation.
* `fetchurl' accepts parameters `sha256' and `sha1' in addition to
`md5'.
* `nix-prefetch-url' now prints out a SHA-1 hash in base-32. (TODO: a
flag to specify the hash.)
substitute mechanism) creates a store path by downloading full NAR
archives and/or patches specified in the available manifests.
Any combination of present paths, full downloads, and patches can be
used to construct the target path. In particular, patches can be
chained in sequence; and full NAR archives of the target path can be
omitted (i.e., patch-only deployment is possible). A shortest path
algorithm is used to find the smallest set of files to be downloaded
(the edge weights are currently file sizes, but one can imagine
taking the network speed to the various source into account).
Patches are binary deltas between two store paths. To be precise,
they are the output of the `bsdiff' program applied to the NAR
archives obtained by dumping (`nix-store --dump') the two store
paths. The advantage of diff'ing NAR archives (and not, say, doing
file-by-file diffs) is that file renames/moves are handled
automatically. The disadvantage is that we cannot optimise creation
of unchanged files (by hard-linking).
The expression `with E1; E2' evaluates to E2 with all bindings in
the attribute set E1 substituted. E.g.,
with {x = 123;}; x
evaluates to 123. That is, the attribute set E1 is in scope in E2.
This is particularly useful when importing files containing lots
definitions. E.g., instead of
let {
inherit (import ./foo.nix) a b c d e f;
body = ... a ... f ...;
}
we can now say
with import ./foo.nix;
... a ... f ...
I.e., we don't have to say what variables should be brought into scope.
Nix expressions.
To subscribe to a channel (needs to be done only once):
nix-channel --add \
http://catamaran.labs.cs.uu.nl/dist/nix/channels/nixpkgs-unstable
This just adds the given URL to ~/.nix-channels (which can also be
edited manually).
To update from all channels:
nix-channel --update
This fetches the latest expressions and pulls cache manifests. The
default Nix expression (~/.nix-defexpr) is made to point to the
conjunction of the expressions downloaded from all channels.
So to update all installed derivations in the current user
environment:
nix-channel --update
nix-env --upgrade '*'
If you are really courageous, you can put this in a cronjob or
something.
You can subscribe to multiple channels. It is not entirely clear
what happens when there are name clashes between derivations from
different channels. From nix-env/main.cc it appears that the one
with the lowest (highest?) hash will be used, which is pretty
meaningless.
* Fixed a segfault caused by the buffering of stderr.
* Fix now allows the specification of the full output path. This
should be used with great care, since it by-passes the normal hash
generation.
* Incremented the version number to 0.4 (prerelease).
substituting for (obvious, really).
* For greater efficiency, nix-pull/unnar will place the output in a
path that is probably the same as what is actually needed, thus
preventing a path copy.
* Even if a output id is given in a Fix package expression, ensure
that the resulting Nix derive expression has a different id. This
is because Nix expressions that are semantically equivalent (i.e.,
build the same result) might be different w.r.t. efficiency or
divergence. It is absolutely vital for the substitute mechanism
that such expressions are not used interchangeably.
value; this potentially dangerous feature enables better
sharing for those paths for which the content is known in
advance (e.g., because a content hash is given).
* Fast builds: if we can expand all output paths of a derive
expression, we don't have to build.
number of bytes, e.g., in case of a signal like SIGSTOP.
This caused `nix --dump' to fail sometimes.
Note that this bug went unnoticed because the call to `nix
--dump' is in a pipeline, and the shell ignores non-zero
exit codes from all but the last element in the pipeline.
Is there any way to check the result of the initial elements
in the pipeline? (In other words, is it at all possible to
write reliable shell scripts?)
hash for which no local expansion is available, Nix can execute a
`substitute' which should produce a path with such a hash.
This is policy-free since Nix does not in any way specify how the
substitute should work, i.e., it's an arbitrary (unnormalised)
fstate expression. For example, `nix-pull' registers substitutes
that fetch Nix archives from the network (through `wget') and unpack
them, but any other method is possible as well. This is an
improvement over the old Nix sharing scheme, which had a policy
(fetching through `wget') built in.
The sharing scheme doesn't work completely yet because successors
from fstate rewriting have to be registered on the receiving side.
Probably the whole successor stuff can be folded up into the
substitute mechanism; this would be a nice simplification.
archives (using the package in corepkgs/nar).
* queryPathByHash -> expandHash, and it takes an argument specifying
the target path (which may be empty).
* Install the core Fix packages in $prefix/share/fix. TODO: bootstrap
Nix and install Nix as a Fix package.
