Las

It's just "build system improvements" in general.

So I'm wondering, why do we need to update the materialisation result manually?

Is it because the cost of evaluating the materisaliation derivation itself is expensive?

What would happen if we rather than getting the materialisation file from the git repo, just generate it with a Nix derivation, and pass that to haskell.nix? That way we...

OK, so there's no fundamental reason to it being slow, besides it just being unoptimised then I assume? This should theoretically be very simple. You just need to make sure...

You can make sure it's cached if the *.cabal files etc. haven't changed. And you need to update the materialisation if you do that anyway.

The potentially problematic issue here is that we need to filter out all the irrelevant files from the source, and unfortunately we might need ca-derivations to detect that nothing has...

I think you're thinking precisely of the issue I just noted. The solution in current stable Nix is to fix the hash and make it content-addressed that way. The real...

You filter the source at evaluation-time AFAICT, which is part of what might be making it slow potentially.

I'll try making a PoC that shows how you can do materialisation without it being a PITA then!