I don’t agree with that characterization. The scope of the flakes RFC was pretty limited: it provides a standard way to define multi-repository Nix projects. This consists of the flake.nix structure, a way to define dependencies on other repos (inputs), and a lock file format. What it didn’t do:
- Define any flake outputs. (This is up to tools such as
nixand Hydra.) - Define a flake URL format. (I.e. the “Nix resources”.)
- Define a registry.
- Replace any existing configuration/composition mechanisms in the Nix ecosystem, such as Nixpkgs overlays and NixOS modules.
- Make any language changes.
- Add a type system for defining the type of outputs. (IIRC this was part of Shea’s original flakes proposal.)
- Add a module system.
To quote the RFC: Flakes allow hermetic, reproducible evaluation of multi-repository Nix projects; impose a discoverable, standard structure on Nix projects; and replace previous mechanisms such as Nix channels and the Nix search path.
Step 3 seems to ignore the work done in the last couple of years. Nix 2.4 is the first flakes-enabled version of Nix and it has flake-enabled versions of nix search, nix-env -i and nix-channel. (nixos-rebuild is in another project.)
In case you didn’t see it, there is a proposed roadmap that suggests stabilizing flakes and the new CLI in the next few 2.x releases, and doing a 3.0 release when we’re prepared to call them stable.