| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
nix: allow using --file - to read from stdin
|
|
|
|
Co-authored-by: Théophane Hufschmitt <7226587+thufschmitt@users.noreply.github.com>
|
|
|
|
Fixes #6193.
|
|
|
|
The tests are scheduled in the order they appear, so running the long
ones first slightly improves the scheduling.
On my machine, this decreases the time of `make install` from 40s to 36s
|
|
|
|
It’s totally valid to have entries in `NIX_PATH` that aren’t valid paths
(they can even be arbitrary urls or `channel:<channel-name>`).
Fix #5998 and #5980
|
|
Always good to have :)
|
|
|
|
|
|
flakes: search up to git or filesystem boundary
|
|
|
|
|
|
Rewrite the string taken by the IFD-like primops to contain the actual
output paths of the derivations rather than the placeholders
Fix #5805
|
|
While parsing a flakeref, upon not finding a flake.nix, search upwards
until git or filesystem boundary.
|
|
|
|
Make the flake options work when using the daemon
|
|
When setting flake-local options (with the `nixConfig` field), forward
these options to the daemon in case we’re using one.
This is necessary in particular for options like `binary-caches` or
`post-build-hook` to make sense.
Fix <https://github.com/NixOS/nix/commit/343239fc8a1993f707a990c2cd54a41f1fa3de99#r44356843>
|
|
When running a `:b` command in the repl, after building the derivations
query the store for its outputs rather than just assuming that they are
known in the derivation itself (which isn’t true for CA derivations)
Fix #5328
|
|
|
|
Based off on @dtzWill's #2276
|
|
|
|
Make sure that we can’t build the same derivation twice at the same
time.
Fix https://github.com/NixOS/nix/issues/5029
|
|
Fill `NIX_CONFIG` with the value of the current Nix configuration before
calling the nix subprocesses in the repl
That way the whole configuration (including the possible
`experimental-features`, a possibly `--store` option or whatever) will
be made available.
This is required for example to make `nix repl` work with a custom
`--store`
|
|
Make the CA tests actually test something
|
|
Add an access-control list to the realisations in recursive-nix (similar
to the already existing one for store paths), so that we can build
content-addressed derivations in the restricted store.
Fix #4353
|
|
Fix #4837
|
|
Gracefully handle duplicate realisations
|
|
Make `nix-shell` support content-addressed derivations
|
|
|
|
Make `computeFSClosure` ca-aware
|
|
In case a previous interrupted build left a garbage path laying around,
remove it before trying to move the path to its final location.
Fix #4858
|
|
Also add a small architecture to easily run CA-enabled tests
|
|
Resolve the derivation before trying to load its environment −
essentially reproducing what the build loop does − so that we can
effectively access our dependencies (and not just their placeholders).
Fix #4821
|
|
When adding a path to the local store (via `LocalStore::addToStore`),
ensure that the `ca` field of the provided `ValidPathInfo` does indeed
correspond to the content of the path.
Otherwise any untrusted user (or any binary cache) can add arbitrary
content-addressed paths to the store (as content-addressed paths don’t
need a signature).
|
|
|
|
|
|
|
|
Doesn't make sense anymore with the new setup
|
|
|
|
This requires adding `nix` to its own closure which is a bit unfortunate,
but as it is optional (the test will be disabled if `OUTER_NIX` is unset) it
shouldn't be too much of an issue.
(Ideally this should go in another derivation so that we can build Nix and run
the test independently, but as the tests are running in the same derivation
as the build it's a bit complicated to do so).
|
|
Fixes syntax error introduced in 54ced9072b94515a756e1e8e76c92a42f0ccf366.
|
|
Restore now-working build-remote-content-addressed-fixed test
|
|
Broken atm
|
|
|
|
Requires a slight update to the test infra to work properly, but
having the possibility to group tests that way makes the whole thing
quite cleaner imho
|
