Flakes advantages are sometimes more immediately noticeable when not running NixOS, since the unstructured nix expression system used by default in that scenari

Flakes advantages are sometimes more immediately noticeable when not running NixOS, since the unstructured nix expression system used by default in that scenario is not helpful Vs a flake with its structure allowing a standardized way to express many things. With a project specific flake you can specify not only how to build your package, and how to run it, (includable ability to specify "apps" for each executable of a multi-executable package), but also specify a development environment for developing on the package with the exact compiler versions and everything this package wants. (The convenience of a development container, but without limitations of developing in a container.) This can obviously be extended further to defining nixos modules, which could be useful if your package is a service that people might want to pull in to nixos. -- Some flake features like defining nixosConfigurations or homeConfigurations are not really sensible for a package-specific flake but can be useful if defining a flake for say your lab of NixOS systems. That is one advantage over classic nixos configurations. You can have a flake that defines the configurations of multiple systems. Indeed, even if you don't want one master flake for all your machines, you may still want a separate flake for your a home-manager configuration that you can pull in when defining a specific system in a system-specific flake.