| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Shell completion improvements
|
|
In particular, this means that 'nix eval` (which uses toValue()) no
longer auto-calls functions or functors (because
AttrCursor::findAlongAttrPath() doesn't).
Fixes #6152.
Also use ref<> in a few places, and don't return attrpaths from
getCursor() because cursors already have a getAttrPath() method.
|
|
Allowing this is a potential security hole, since it allows the user
to specify parameters like 'local-nar-cache'.
|
|
https://hydra.nixos.org/build/171351131
|
|
Impure derivations
|
|
|
|
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
outputHashAlgo = "sha256";
outputHashMode = "recursive";
buildCommand = "date > $out";
};
Some important characteristics:
* This requires the 'impure-derivations' experimental feature.
* Impure derivations are not "cached". Thus, running "nix-build" on
the example above multiple times will cause a rebuild every time.
* They are implemented similar to CA derivations, i.e. the output is
moved to a content-addressed path in the store. The difference is
that we don't register a realisation in the Nix database.
* Pure derivations are not allowed to depend on impure derivations. In
the future fixed-output derivations will be allowed to depend on
impure derivations, thus forming 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.
|
|
BaseError::addTrace(...) returns a BaseError, but we want to
throw a TypeError instead.
Fixes #6336.
|
|
Rather than having four different but very similar types of hashes, make
only one, with a tag indicating whether it corresponds to a regular of
deferred derivation.
This implies a slight logical change: The original Nix+multiple-outputs
model assumed only one hash-modulo per derivation. Adding
multiple-outputs CA derivations changed this as these have one
hash-modulo per output. This change is now treating each derivation as
having one hash modulo per output.
This obviously means that we internally loose the guaranty that
all the outputs of input-addressed derivations have the same hash
modulo. But it turns out that it doesn’t matter because there’s nothing
in the code taking advantage of that fact (and it probably shouldn’t
anyways).
The upside is that it is now much easier to work with these hashes, and
we can get rid of a lot of useless `std::visit{ overloaded`.
Co-authored-by: John Ericson <John.Ericson@Obsidian.Systems>
|
|
|
|
|
|
|
|
Fixes #5523.
|
|
experimental feature is enabled
This allows writing fallback code like
if builtins ? fetchClosure then
builtins.fetchClose { ... }
else
builtins.storePath ...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The advantage is that the resulting closure doesn't need to be signed,
so you don't need to configure any binary cache keys on the client.
|
|
|
|
|
|
This allows closures to be imported at evaluation time, without
requiring the user to configure substituters. E.g.
builtins.fetchClosure {
storePath = /nix/store/f89g6yi63m1ywfxj96whv5sxsm74w5ka-python3.9-sqlparse-0.4.2;
from = "https://cache.ngi0.nixos.org";
}
|
|
docs: genericClosure
|
|
|
|
Before the change lexter errors did not report the location:
$ nix build -f. mc
error: path has a trailing slash
(use '--show-trace' to show detailed location information)
Note that it's not clear what file generates the error.
After the change location is reported:
$ src/nix/nix --extra-experimental-features nix-command build -f ~/nm mc
error: path has a trailing slash
at .../pkgs/development/libraries/glib/default.nix:54:18:
53| };
54| src = /tmp/foo/;
| ^
55|
(use '--show-trace' to show detailed location information)
Here we see both problematic file and the string itself.
|
|
Fixes #6243.
|
|
This ensures that it doesn't get parsed as a valid Nix expression.
|
|
Decode string context straight to using StorePaths
|
|
I gather decoding happens on demand, so I hope don't think this should
have any perf implications one way or the other.
|
|
|
|
|
|
Easier than using dummy path with input addressed.
|
|
1. `DerivationOutput` now as the `std::variant` as a base class. And the
variants are given hierarchical names under `DerivationOutput`.
In 8e0d0689be797f9e42f9b43b06f50c1af7f20b4a @matthewbauer and I
didn't know a better idiom, and so we made it a field. But this sort
of "newtype" is anoying for literals downstream.
Since then we leaned the base class, inherit the constructors trick,
e.g. used in `DerivedPath`. Switching to use that makes this more
ergonomic, and consistent.
2. `store-api.hh` and `derivations.hh` are now independent.
In bcde5456cc3295061a0726881c3e441444dd6680 I swapped the dependency,
but I now know it is better to just keep on using incomplete types as
much as possible for faster compilation and good separation of
concerns.
|
|
nix-env: always print output names in JSON and XML
|
|
The current `--out-path` flag has two disadvantages when one is only
concerned with querying the names of outputs:
- it requires evaluating every output's `outPath`, which takes
significantly more resources and runs into more failures
- it destroys the information of the order of outputs so we can't tell
which one is the main output
This patch makes the output names always present (replacing paths with
`null` in JSON if `--out-path` isn't given), and adds an `outputName`
field.
|
|
|
|
This changes was taken from dynamic derivation (#4628). It` somewhat
undoes the refactors I first did for floating CA derivations, as the
benefit of hindsight + requirements of dynamic derivations made me
reconsider some things.
They aren't to consequential, but I figured they might be good to land
first, before the more profound changes @thufschmitt has in the works.
|
|
|
|
be more memory friendly
|
|
|
|
|
|
|
|
reduces peak hep memory use on eval of our test system from 264.4MB to 242.3MB,
possibly also a slight performance boost.
theoretically memory use could be cut down by another eight bytes per Pos on
average by turning it into a tuple containing an index into a global base
position table with row and column offsets, but that doesn't seem worth the
effort at this point.
|
|
these functions are called a whole lot, and they're all comparatively small.
always inlining them gives ~0.7% performance boost on eval.
before:
Benchmark 1: nix flakes search --no-eval-cache --offline ../nixpkgs hello
Time (mean ± σ): 6.935 s ± 0.052 s [User: 5.852 s, System: 0.853 s]
Range (min … max): 6.808 s … 7.026 s 20 runs
Benchmark 2: nix flakes eval -f ../nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix
Time (mean ± σ): 329.8 ms ± 2.7 ms [User: 299.0 ms, System: 30.8 ms]
Range (min … max): 326.6 ms … 336.5 ms 20 runs
Benchmark 3: nix flakes eval --raw --impure --file expr.nix
Time (mean ± σ): 2.655 s ± 0.038 s [User: 2.364 s, System: 0.220 s]
Range (min … max): 2.574 s … 2.737 s 20 runs
after:
Benchmark 1: nix flakes search --no-eval-cache --offline ../nixpkgs hello
Time (mean ± σ): 6.912 s ± 0.036 s [User: 5.823 s, System: 0.856 s]
Range (min … max): 6.849 s … 6.980 s 20 runs
Benchmark 2: nix flakes eval -f ../nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix
Time (mean ± σ): 325.1 ms ± 2.5 ms [User: 293.2 ms, System: 31.8 ms]
Range (min … max): 322.2 ms … 332.8 ms 20 runs
Benchmark 3: nix flakes eval --raw --impure --file expr.nix
Time (mean ± σ): 2.636 s ± 0.024 s [User: 2.352 s, System: 0.226 s]
Range (min … max): 2.574 s … 2.681 s 20 runs
|
|
vast majority of envs is this size.
before:
Benchmark 1: nix flakes search --no-eval-cache --offline ../nixpkgs hello
Time (mean ± σ): 6.946 s ± 0.041 s [User: 5.875 s, System: 0.835 s]
Range (min … max): 6.834 s … 7.005 s 20 runs
Benchmark 2: nix flakes eval -f ../nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix
Time (mean ± σ): 330.3 ms ± 2.5 ms [User: 299.2 ms, System: 30.9 ms]
Range (min … max): 327.5 ms … 337.7 ms 20 runs
Benchmark 3: nix eval --raw --impure --expr 'with import <nixpkgs/nixos> {}; system'
Time (mean ± σ): 2.671 s ± 0.035 s [User: 2.370 s, System: 0.232 s]
Range (min … max): 2.597 s … 2.749 s 20 runs
after:
Benchmark 1: nix flakes search --no-eval-cache --offline ../nixpkgs hello
Time (mean ± σ): 6.935 s ± 0.052 s [User: 5.852 s, System: 0.853 s]
Range (min … max): 6.808 s … 7.026 s 20 runs
Benchmark 2: nix flakes eval -f ../nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix
Time (mean ± σ): 329.8 ms ± 2.7 ms [User: 299.0 ms, System: 30.8 ms]
Range (min … max): 326.6 ms … 336.5 ms 20 runs
Benchmark 3: nix flakes eval --raw --impure --file expr.nix
Time (mean ± σ): 2.655 s ± 0.038 s [User: 2.364 s, System: 0.220 s]
Range (min … max): 2.574 s … 2.737 s 20 runs
|
|
turns out it's only necessary for MANUAL_VDB, which nix doesn't use. omitting
them gives a slight performance improvement on eval.
before:
Benchmark 1: nix flakes search --no-eval-cache --offline ../nixpkgs hello
Time (mean ± σ): 6.988 s ± 0.061 s [User: 5.935 s, System: 0.845 s]
Range (min … max): 6.865 s … 7.075 s 20 runs
Benchmark 2: nix flakes eval -f ../nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix
Time (mean ± σ): 332.6 ms ± 3.9 ms [User: 299.6 ms, System: 32.9 ms]
Range (min … max): 328.1 ms … 339.1 ms 20 runs
Benchmark 3: nix eval --raw --impure --expr 'with import <nixpkgs/nixos> {}; system'
Time (mean ± σ): 2.681 s ± 0.049 s [User: 2.382 s, System: 0.228 s]
Range (min … max): 2.607 s … 2.776 s 20 runs
after:
Benchmark 1: nix flakes search --no-eval-cache --offline ../nixpkgs hello
Time (mean ± σ): 6.946 s ± 0.041 s [User: 5.875 s, System: 0.835 s]
Range (min … max): 6.834 s … 7.005 s 20 runs
Benchmark 2: nix flakes eval -f ../nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix
Time (mean ± σ): 330.3 ms ± 2.5 ms [User: 299.2 ms, System: 30.9 ms]
Range (min … max): 327.5 ms … 337.7 ms 20 runs
Benchmark 3: nix eval --raw --impure --expr 'with import <nixpkgs/nixos> {}; system'
Time (mean ± σ): 2.671 s ± 0.035 s [User: 2.370 s, System: 0.232 s]
Range (min … max): 2.597 s … 2.749 s 20 runs
|
