| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
The name ‘nixPath’ breaks existing code.
|
|
|
|
src/libexpr/primops.cc:42:8: error: looser throw specifier for 'virtual nix::InvalidPathError::~InvalidPathError()'
src/libexpr/nixexpr.hh:12:1: error: overriding 'virtual nix::EvalError::~EvalError() noexcept (true)'
http://hydra.nixos.org/build/12385750
|
|
Fixes #294.
|
|
allow-arbitrary-code-during-evaluation option is true (default false)
|
|
This can be used to import a dynamic shared object and return an
arbitrary value, including new primops. This can be used both to test
new primops without having to recompile nix every time, and to build
specialized primops that probably don't belong upstream (e.g. a function
that calls out to gpg to decrypt a nixops secret as-needed).
The imported function should initialize the Value & as needed. A single
import can define multiple values by creating an attrset or list, of
course.
An example initialization function might look like:
extern "C" void initialize(nix::EvalState & state, nix::Value & v)
{
v.type = nix::tPrimOp;
v.primOp = NEW nix::PrimOp(myFun, 1, state.symbols.create("myFun"));
}
Then `builtins.importNative ./example.so "initialize"` will evaluate to
the primop defined in the myFun function.
|
|
We're not catching these anywhere.
|
|
|
|
In addition to reducing duplication, this fixes both import from
derivation and import of derivation for scopedImport
|
|
There really is no case I can think of where taking the context into
account is useful. Mostly it's just very inconvenient.
|
|
|
|
|
|
It's slower than ExprVar since it doesn't compute a static
displacement. Since we're not using the throw primop in the
implementation of <...> anymore, it's also not really needed.
|
|
Nix search path lookups like <nixpkgs> are now desugared to ‘findFile
nixPath <nixpkgs>’, where ‘findFile’ is a new primop. Thus you can
override the search path simply by saying
let
nixPath = [ { prefix = "nixpkgs"; path = "/my-nixpkgs"; } ];
in ... <nixpkgs> ...
In conjunction with ‘scopedImport’ (commit
c273c15cb13bb86420dda1e5341a4e19517532b5), the Nix search path can be
propagated across imports, e.g.
let
overrides = {
nixPath = [ ... ] ++ builtins.nixPath;
import = fn: scopedImport overrides fn;
scopedImport = attrs: fn: scopedImport (overrides // attrs) fn;
builtins = builtins // overrides;
};
in scopedImport overrides ./nixos
|
|
Also fixes #261.
|
|
It contains the Nix expression search path as a list of { prefix, path
} sets, e.g.
[ { path = "/nix/var/nix/profiles/per-user/root/channels/nixos"; prefix = ""; }
{ path = "/etc/nixos/configuration.nix"; prefix = "nixos-config"; }
{ path = "/home/eelco/Dev/nix/inst/share/nix/corepkgs"; prefix = "nix"; }
]
|
|
‘scopedImport’ works like ‘import’, except that it takes a set of
attributes to be added to the lexical scope of the expression,
essentially extending or overriding the builtin variables. For
instance, the expression
scopedImport { x = 1; } ./foo.nix
where foo.nix contains ‘x’, will evaluate to 1.
This has a few applications:
* It allows getting rid of function argument specifications in package
expressions. For instance, a package expression like:
{ stdenv, fetchurl, libfoo }:
stdenv.mkDerivation { ... buildInputs = [ libfoo ]; }
can now we written as just
stdenv.mkDerivation { ... buildInputs = [ libfoo ]; }
and imported in all-packages.nix as:
bar = scopedImport pkgs ./bar.nix;
So whereas we once had dependencies listed in three places
(buildInputs, the function, and the call site), they now only need
to appear in one place.
* It allows overriding builtin functions. For instance, to trace all
calls to ‘map’:
let
overrides = {
map = f: xs: builtins.trace "map called!" (map f xs);
# Ensure that our override gets propagated by calls to
# import/scopedImport.
import = fn: scopedImport overrides fn;
scopedImport = attrs: fn: scopedImport (overrides // attrs) fn;
# Also update ‘builtins’.
builtins = builtins // overrides;
};
in scopedImport overrides ./bla.nix
* Similarly, it allows extending the set of builtin functions. For
instance, during Nixpkgs/NixOS evaluation, the Nixpkgs library
functions could be added to the default scope.
There is a downside: calls to scopedImport are not memoized, unlike
import. So importing a file multiple times leads to multiple parsings
/ evaluations. It would be possible to construct the AST only once,
but that would require careful handling of variables/environments.
|
|
|
|
|
|
Otherwise you just get ‘expected string `Derive(['’ which isn't very helpful.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For example:
error: `tail' called on an empty list, at
/home/eelco/Dev/nixpkgs/pkgs/applications/misc/hello/ex-2/default.nix:13:7
|
|
|
|
This allows error messages like:
error: the anonymous function at `/etc/nixos/configuration.nix:1:1'
called without required argument `foo', at
`/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/lib/modules.nix:77:59'
|
|
The newEnv variable was accessed (via the dynamicEnv) pointer after it
had gone out of scope.
Fixes #234.
|
|
|
|
|
|
|
|
|
|
This reverts commit 273322c7732093a354e86df82cf75d6604b8bce8.
|
|
If we're evaluating some application ‘v = f x’, we can't store ‘f’
temporarily in ‘v’, because if ‘f x’ refers to ‘v’, it will get ‘f’
rather than an infinite recursion error.
Unfortunately, this breaks the tail call optimisation introduced in
c897bac54954373f63511702731fe2cb23c0c98e.
Fixes #217.
|
|
Fixes #121. Note that we don't warn about missing $NIX_PATH entries
because it's intended that some may be missing (cf. the default
$NIX_PATH on NixOS, which includes paths like /etc/nixos/nixpkgs for
backward compatibility).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
