meta/architecture-docs/on-flakes.md

Use more principled dependency management than flakes

As per nix.dev:

Flakes emphasize reproducible artifacts and convenience for their consumers, while classic Nix tools center around composable building blocks and customisation options for developers.

We have currently used nix flakes to:

• manage project dependencies
• specify:

Parts of our project that touch upon flakes:

• our dependency management
• how we interface with dependencies
• how we (might) expose packages at upstream repositories, to facilitate e.g. nix run
• the interface we expose (to users + nixops4)
  • architectures
  • formatter
  • checks
  • pre-commit hooks
  • development shell
  • configuration for nixos / nixops

Flakes aim to address various topics at once - as per their introduction including composability, reproducibility, offering a consistent UI, and discoverability. Technical issues aside, they have drawn criticism including:

• trying too many things at once (Unix philosophy)
• dependency explosion, no support to pass arguments, eagerly copying flake directories to the store, bad UX
• locking dependencies of subprojects

Alternatives:

• dependency management: after a bug fix maybe better done using npins, which makes this more explicit, while flakes' caching may help for say Nixpkgs
• how we interface with dependencies: mostly can be done without flakes, which may in fact help prevent pulling in recursive dependencies we do not use
• how we (might) expose packages at upstream repositories, to facilitate e.g. nix run: no good alternatives for nix run exist currently, aside from it seeming preferable to defer deviating from the norm here to community RFCs
• the interface we expose: flakes ignore unstaged files, cache at the cost of eagerly copying flake directories to the store, don't support passing arguments, make it harder to evaluate just part of a project