| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
containing functions that operate on the Nix store. One
implementation is LocalStore, which operates on the Nix store
directly. The next step, to enable secure multi-user Nix, is to
create a different implementation RemoteStore that talks to a
privileged daemon process that uses LocalStore to perform the actual
operations.
|
|
|
|
|
|
Rather, setuid support is now always compiled in (at least on
platforms that have the setresuid system call, e.g., Linux and
FreeBSD), but it must enabled by chowning/chmodding the Nix
binaries.
|
|
(NIX-70)
|
|
|
|
gives a huge speedup in operations that read or write from standard
input/output. (So libstdc++'s I/O isn't that bad, you just have to
call std::ios::sync_with_stdio(false).) For instance, `nix-store
--register-substitutes' went from 1.4 seconds to 0.1 seconds on a
certain input. Another victory for Valgrind.
|
|
now that reference scanning is sufficiently streamy.
|
|
graph to be passed to a builder. This attribute should be a list of
pairs [name1 path1 name2 path2 ...]. The references graph of each
`pathN' will be stored in a text file `nameN' in the temporary build
directory. The text files have the format used by `nix-store
--register-validity'. However, the deriver fields are left empty.
`exportReferencesGraph' is useful for builders that want to do
something with the closure of a store path. Examples: the builders
that make initrds and ISO images for NixOS.
`exportReferencesGraph' is entirely pure. It's necessary because
otherwise the only way for a builder to get this information would
be to call `nix-store' directly, which is not allowed (though
unfortunately possible).
|
|
this in the NixOS installer (or in the buildfarm) to ensure that the
cryptographic hash of the path contents still matches the actual
contents.
|
|
|
|
|
|
available. For instance,
$ nix-store -l $(which svn) | less
lets you read the build log of the Subversion instance in your
profile.
* `nix-store -qb': if applied to a non-derivation, take the deriver.
|
|
|
|
|
|
|
|
check that the references of the output of a derivation are in the
specified set. For instance,
allowedReferences = [];
specifies that the output cannot have any references. (This is
useful, for instance, for the generation of bootstrap binaries for
stdenv-linux, which must not have any references for purity). It
could also be used to guard against undesired runtime dependencies,
e.g.,
{gcc, dynlib}: derivation {
...
allowedReferences = [dynlib];
}
says that the output can refer to the path of `dynlib' but not
`gcc'. A `forbiddedReferences' attribute would be more useful for
this, though.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
non-store paths to a builder.
|
|
|
|
|
|
concatenation and string coercion. This was a big mess (see
e.g. NIX-67). Contexts are now folded into strings, so that they
don't cause evaluation errors when they're not expected. The
semantics of paths has been clarified (see nixexpr-ast.def).
toString() and coerceToString() have been merged.
Semantic change: paths are now copied to the store when they're in a
concatenation (and in most other situations - that's the
formalisation of the meaning of a path). So
"foo " + ./bla
evaluates to "foo /nix/store/hash...-bla", not "foo
/path/to/current-dir/bla". This prevents accidental impurities, and
is more consistent with the treatment of derivation outputs, e.g.,
`"foo " + bla' where `bla' is a derivation. (Here `bla' would be
replaced by the output path of `bla'.)
|
|
|
|
|
|
kind of notation for strings.
|
|
expression resides in the store.
|
|
work, where x is a store path.
|
|
|
|
argument.
|
|
suffix, e.g., `builtins.toFile "builder.sh" "..."'.
* toFile: handle references to other files correctly.
|
|
|
|
|
|
|
|
(e.g., "java-front-0.9pre15899" instead of "java-front";
particularly important when doing upgrades later on).
|
|
side should be a path, I guess.
* Handle paths that are in the store but not direct children of the
store directory.
* Ugh, hack to prevent double context wrapping.
|
|
* Primop `pathExists' to check for path existence.
|
|
|
|
|
|
* Put common test functions in tests/lang/lib.nix.
|
|
With this primitive, a list-flattening function can be implemented
(NIX-55, example is in tests/lang/eval-okay-flatten.nix).
|
|
list. Useful for lots of things, such as implementing a fold
function (see NIX-30, example is in tests/lang/eval-okay-list.nix).
|
|
attribute existence and to return an attribute from an attribute
set, respectively. Example: `hasAttr "foo" {foo = 1;}'. They
differ from the `?' and `.' operators in that the attribute name is
an arbitrary expression. (NIX-61)
|
|
regular files into memory all at once.
|
