It is not copying the full repository, but “only” the staging area/commit.
If it was copying full repository, working on nixpkgs would kill many peoples store…
Copying 50,000 files takes a while on my machine, and doing so for every single line change is very frustrating. That’s why I don’t use flakes when working on nixpkgs. At work, we have one large multi-package monorepo, and working on one package with flakes is an even worse experience than working on nixpkgs. Single checkout of this monorepo is around 300MB and building one package 50 times consumes ~15GB of space in /nix/store.
3 Likes
I wonder if nix.settings.auto-optimise-store = true; would mitigate most of the duplication you see from copying .nix expressions to the store. It’s still not instant. But at least it will save some space for you.
It is an “after the fact” optimisation, which means, the full store path is created, and then scanned for “duplicate” files, which will be replaced with hardlinks to identical files.
So instead of making things quicker, it will in fact make them slower, due to the after the fact scanning. Copying will happen anyway.
2 Likes
Deep down this whole thing come from the fact that we take the input as a git repo instead of a hash of a bundle of files.
This is my biggest problem with flakes. Treating a flake as a git repo should be an optimisation, not the default.
4 Likes
It is not the default.
The default is to infer the type if none is specified.
So nix will first check if the potential flake location is path-like. If it is, it will be checked whether or not this path is part of a source code repository. If it is, (git or mercurial or svnor whatever else is supported) then the repo type will be used.
If its not, the path will be interpreted as that… path:.
If that can not be resolved into a valid flake, flake: is infered and checked against the registry.
So git is not a default, but “prefered if available”.
If you do not want to use git (for whatever reason) for a local checkout/clone, use path: explicitely.
5 Likes