Flakes for development in large repos

Hello,

I’d really like to use flakes for setting up consistent development environments/shells for my projects. I’ve run into the problem that if the flake.nix is part of a git repo, nix always copies the whole repo to the nix store first, despite the fact that except for the flake.nix, all of it is completely unrelated source code. For my larger repo this is very slow (~10s even if there is nothing to rebuild), also I would prefer not to have all my source code in the public nix store. What is the preferred way to avoid this?

3 Likes

No, flakes are always copied to the store, git repo or not.

You could create a flake located away from your code.

It’s not possible yet, but at least a solution is planned, see Copy local flakes to the store lazily · Issue #3121 · NixOS/nix · GitHub.

do you mean only for dev shells?

something like nix shell github:your/dev-flake#rust-tools ?

How could it be possible for building the tools in a monorepo with a flake located away from your code?

nix develop is for dev shells, not nix shell.
Also, no, I mean in general.

Use a fetcher for the code.
But OP doesn’t want to fetch the code, evidently?

It would be possible to use a separate repo for the flake, but that (kind of) defeats the most awesome feature, which is having a description of you dev environment directly tied to the source code, so once you have the source code, you have the dev environment as well.

I see a few good ways how this could be implemented:

  1. Add a rule (possibly optional) that only paths below the flake.nix gets copied to the store, not parent directories. Then we could just create a nix-stuff directory and put everything there, without all of the source code unrelated to nix being copied.
  2. Add an optional filters parameter to each item in inputs, which allows to specify which files should be copied and which shouldn’t (e.g., `filters = [“+./nix-stuff/**” “-*.c”]).
  3. Have a .nixignore which works like .gitignore but is only parsed by nix.
1 Like

The unfortunate truth is that flakes in their current state are a bad fit for large, frequently changing repos. Efforts to fix that are underway, but they have been underway several years now.

The good news is that pretty much anything you can achieve with flakes, you can achieve without flakes. It just might take more work and you’ll be a little off the beaten path.

(Note that when I say “without flakes” I just mean no flake.nix, but not necessarily restricting yourself only to the stable command line).