it's a very magical attrset, let's just take it for granted and link to reference documentation
But you can literally lib.fileset.subtract <this> <deployment/check>
git-hooks
from npins
Not exactly convinced we should give carte blanche here as it may bloat the closure, I'd at least wish for a comment that reassures us this is a good idea.
Yes agreed. And I didn't imply we should do anything about that in this PR.
Regarding the slowness -- do we even need the flake-under-test to have flake inputs? If we make the right store paths available in the test VM (e.g. by mounting the host store) we may as well get the sources in that flake-under-test from npins and save ourselves the lock override.
Arguably we don't need flake inputs here at all as we can pass store paths via sources
here, which means we don't need flakes at all at the project level (unless flake-parts wants a root flake to do its thing). Not saying we need to pull through with that now, just trying to separate accidental from essential complexity.
It may be worth noting here that we're otherwise using the entire repository as is. Otherwise it's slightly too magical when you try to trace it through in your head.
mkFlake
to own file - get flake-parts
from npins
Could be! I’ll think about it. Not a priority right now though.
mkFlake
to own file - get flake-parts
from npins
I was not planning to have any other changes to dependencies in the extraction of the flake under test.
I presume the flake under test will simply take the inputs in the current flake.nix
,…
mkFlake
to own file - get flake-parts
from npins
Do I understand correctly that the next step will be extracting the flake under test, which will probably take the remaining flake inputs with it?
I think we should split this into deployment data model (almost done) and migration data model (still needs research).