# Use more principled dependency management than flakes

As per [nix.dev](https://nix.dev/concepts/flakes#should-i-use-flakes-in-my-project):

> 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](https://github.com/NixOS/rfcs/pull/49) 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](https://www.tweag.io/blog/2020-05-25-flakes/#what-problems-do-flakes-solve) including composability, reproducibility, offering a consistent UI, and discoverability - [technical issues](https://discourse.nixos.org/t/nix-flakes-is-an-experiment-that-did-too-much-at-once/32707/3) aside has drawn criticism including:

- [trying too many things at once](https://samuel.dionne-riel.com/blog/2023/09/06/flakes-is-an-experiment-that-did-too-much-at-once.html) (Unix philosophy)
- [dependency explosion, no support to pass arguments, eagerly copying flake directories to the store, bad UX](https://discourse.nixos.org/t/experimental-does-not-mean-unstable-detsyss-perspective-on-nix-flakes/32703/2)
- [locking dependencies of subprojects](https://jade.fyi/blog/flakes-arent-real/)
<!-- - [inability to patch flakes](https://github.com/NixOS/rfcs/pull/49#pullrequestreview-262606855) -->
<!-- - [complexity](https://news.ycombinator.com/item?id=40060403) -->
<!-- - [no parameterization, defying Unix philosophy](https://nix.dev/concepts/flakes#why-are-flakes-controversial) -->
<!-- - [not awaiting RFC process](https://discourse.nixos.org/t/why-are-flakes-still-experimental/29317/12) -->
<!-- - [integration into Nix core](https://discourse.nixos.org/t/introducing-flakehub/32044/52) -->
<!-- - [making semantic versioning part of commercial project Flakehub rather than of Nix itself](https://discourse.nixos.org/t/introducing-flakehub/32044/31) -->
<!-- - [commercial interests](https://discourse.nixos.org/t/introducing-flakehub/32044/24) -->
<!-- - [open letter](https://save-nix-together.org/): undermining community processes by declaring flakes stable -->

Alternatives:

- dependency management: after a [bug](https://github.com/andir/npins/issues/57) 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](https://github.com/NixOS/nix/pull/4702#issuecomment-2233787312), 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