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

While its RFC was drafted and implemented by Nix creator Eelco Dolstra thru Tweag (which is now divided on flakes) on behalf of Target (which we no longer have indication still uses nix), its aim to address various topics at once - as per their introduction including composability, reproducibility, offering a consistent UI, and discoverability - appears to have yielded mixed results, flying in the face of the Unix philosophy, and drawing criticism from various prominent community members, including:

• samueldr (author of NixOS Mobile): trying too many things at once (Unix philosophy)
• jade (Lix core member): locking dependencies of subprojects

• raitobezarius (board observer, Lix core member): technical issues
• infinisil (constitutional assembly): dependency explosion, no support to pass arguments, eagerly copying flake directories to the store, bad UX
• sandro (one of the biggest contributors to nixpkgs): making semantic versioning part of commercial project Flakehub rather than of Nix itself
• alyssais (authored Spectrum OS): inability to patch flakes
• tazjin (thru TVL co-authored Tvix): complexity
• jtojnar: not awaiting RFC process
• piegames (formerly member of the moderation team, further contributed 25 commits to dependency management alternative npins): integration into Nix core
• solene: commercial interests

Alternatives:

• dependency management: potentially better done using npins, which makes this more explicit, whereas flakes offer performance improvements when interacting with a large Nix package repository like 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