Tarballs are now unpacked into a content-addressed cache, specifically
a Git repository in ~/.cache/nix/tarball-cache so that we can use
GitAccessor to provide random access.
This makes 'nix build' work on paths (which will be copied to the
store) and store paths (returned as is). E.g. the following flake
output attributes can be built using 'nix build .#foo':
foo = ./src;
foo = self.outPath;
foo = builtins.fetchTarball { ... };
foo = (builtins.fetchTree { .. }).outPath;
foo = builtins.fetchTree { .. } + "/README.md";
foo = builtins.storePath /nix/store/...;
Note that this is potentially risky, e.g.
foo = /.;
will cause Nix to try to copy the entire file system to the store.
What doesn't work yet:
foo = self;
foo = builtins.fetchTree { .. };
because we don't handle attrsets with an outPath attribute in it yet,
and
foo = builtins.storePath /nix/store/.../README.md;
since result symlinks have to point to a store path currently (rather
than a file inside a store path).
Fixes#7417.
This is needed to verify that the source tree served by GitHub hasn't
changed compared to the lock file. Computing the narHash for a nixpkgs
source tree only takes ~0.6s and it's cached. So the cost is fairly
negligible compared to the download time.
InputSchemes now only have a getAccessor(). They could be implemented
internally by fetching the input to the store, but in that case they
will just return a FSInputAccessor.
E.g.
… while evaluating the attribute 'buildCommand' of the derivation 'vm-test-run-github-flakes'
at «github:NixOS/nixpkgs/2fa57ed190fd6c7c746319444f34b5917666e5c1»/pkgs/stdenv/generic/make-derivation.nix:278:7:
This replaces the 'patches' argument to builtins.fetchTree with
something more generic. So instead of 'builtins.fetchTree { patches =
... }' you can do 'builtins.patch { src = builtins.fetchTree { ... };
patchFiles = ... }'.
You can now write
fetchTree {
type = "github";
owner = "NixOS";
repo = "nixpkgs";
rev = "0f316e4d72daed659233817ffe52bf08e081b5de";
patches = [ ./thunderbird-1.patch ./thunderbird-2.patch ];
};
to apply a list of patches to a tree. These are applied lazily - the
patched tree is not materialized unless you do something that causes
the entire tree to be copied to the store (like 'src = fetchTree {
... }'). The equivalent of '-p1' is implied.
File additions/deletions/renames are not yet handled.
Issue #3920.
