[mikepurvis]

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).

[JasonSage]

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.

[mikepurvis]

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.