One thing flakes enable is "easily run some other source".
e.g. to run the latest build of Nix from the GitHub repository NixOS/nix on the master branch, it's:
nix run github:NixOS/nix/master
Or (say) the Helix editor has a flake.nix; so a similar command would work for that. -- Being able to use nix code without having to fetch the source first is pretty neat.
A less contrived example of where this is useful is with Home Manager. Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). -- Whereas with flakes, you can declare Home Manager as an input, so that applying the Home Manager configuration can be done with less effort.
Flakes are like "nix's nix". With nix, you benefit from putting in effort to declare the inputs of some package, and how its outputs are constructed. With nix flakes, you declare where the Nix code you're using comes from.
> If instead of using channels you want to run Home Manager from a Git checkout of the repository then you can use the programs.home-manager.path option to specify the absolute path to the repository.
Neat, though I hope I helped your curiosity regarding why people find flakes useful.
With home-manager, you can declare a flake configuration where home-manager is an input; and then applying the configuration is pretty hands-off since Nix will fetch the appropriate revisions of the inputs.
I think that using flakes is more convenient than the alternatives. (Having to add a channel; or, as you point out, cloning the repository in a consistent path on each system you use & then running that).
I'd say the real alternatives are probably the json-based, pre-flakes pinning tools like Niv, nix-wrangle, and nix-thunk.
They're still less convenient for me than flakes because they don't have great integration with Nix's profile managers (nix-env, nixos-rebuild, home-manager). But they do have fewer quirks in some ways, since they don't try to enforce pure evaluation like the flakes implementation does. They don't worry about whether the pinning happens inside a git repo or whatever.
(I think some orgs that use Nix in production are still using Niv, and haven't touched flakes. Niv is certainly still maintained.)
I used to use Niv, but these days I find it more convenient to just call `builtins.fetchGit` where it's needed, rather than faffing with external files/tools (although https://hackage.haskell.org/package/update-nix-fetchgit can be useful). It's certainly much nicer than the "olden days" of `nixpkgs.fetchgit`, which required an "impure" copy of Nixpkgs (like <nixpkgs>) in order to fetch a pinned copy!
I tend to have a single git repo with my system config, which uses import-from-derivation to grab a bunch of other stuff; and defines a single "package" that's a big `buildEnv` of all the programs I want. That seems to work fine across NixOS (on an old i686 Thinkpad), an old Ubuntu desktop, macOS (a couple of work laptops; old one used nix-darwin, new one just uses nix-env), and I'm currently trying it on nixos-mobile (on my Pinephone).
e.g. to run the latest build of Nix from the GitHub repository NixOS/nix on the master branch, it's:
Or (say) the Helix editor has a flake.nix; so a similar command would work for that. -- Being able to use nix code without having to fetch the source first is pretty neat.A less contrived example of where this is useful is with Home Manager. Setting up Home-Manager without flakes requires adding a channel (or requires using a NixOS module, which only works on NixOS). -- Whereas with flakes, you can declare Home Manager as an input, so that applying the Home Manager configuration can be done with less effort.
Flakes are like "nix's nix". With nix, you benefit from putting in effort to declare the inputs of some package, and how its outputs are constructed. With nix flakes, you declare where the Nix code you're using comes from.