Comment by JasonSage
How do you handle flakes pushing an entire copy of the repo into the nix store? Is this not an issue for you somehow?
How do you handle flakes pushing an entire copy of the repo into the nix store? Is this not an issue for you somehow?
That makes sense. I naively tried flakes for a nix-shell replacement for a couple environments, one was a node app with large node_modules dependencies and the other was a windows app I was running in a local wine root. In both cases re-evaluating the flake was very slow because of the volume of data being copied. I want to do more with flakes but I’m skeptical that they end up being a good per-app workflow when the whole app isn’t using nix for build and dependencies end-to-end.
Yes, that's fair. I wouldn't be trying to use Nix at all if I was wanting to depend on stuff outside of it— fortunately nixpkgs already has decent coverage in the scientific computing space, so most of what we needed for a ROS/robotics application was present, and the remainder wasn't too bad to just package ourselves.
That said, I think the node story overall is still pretty rough. There are several competing tools/workflows each with different tradeoffs. My frontend team did a brief evaluation and basically just noped out of it— there's so much tooling in the node world that just gets you directly from your lockfiles right to a deployable container, it's harder to see the value of a Nix closure as an intermediate build object; the case is a lot less clear for it than for, say, Python or C++ stuff.
The repo being evaluated? Not an issue for me. In the dev scenario disk is plentiful; in production it can be garbage collected out or avoided by using copy-closure type workflows or nix2container (eg just not running nix evaluations directly in the target environment).