3 ms·

> Not only do most users gain very, very little from it How do you come to that conclusion? Those who switch to using flakes are enthusiastic about the improv

> Not only do most users gain very, very little from it How do you come to that conclusion? Those who switch to using flakes are enthusiastic about the improved UX. > flakes is that it is too much added complexity for tiny incremental gains A 'flake' is more/less a set of inputs and a set of outputs. I'd say it's less complicated than a package.json file in an NPM project. The benefits are hard to get otherwise. With flakes, `flake.nix` provides a standard entrypoint to a Nix codebase. Without flakes, you might see a `default.nix`, but would have to read the `default.nix` to know how it's supposed to be called. With flakes, the exact version of Nixpkgs used is locked. Without flakes, I'm not aware of an easy way to do this with channels; and there are a variety of ways (read: no standard way) to do this in Nix code.

lloeki 3y ago
For me the biggest benefits of flakes are: - flake-specific state is fully captured and locked - this locking applies for all platforms the flake targets - extreme ability to be composed The first two solve the same issue as Gemfile.lock, its the PLATFORMS section, and the platform annotations on each of its gem line, which allows `bundle lock` to lock not just for the platform it's being run on but all platforms that are targeted. It also canonicalizes the way to declare targets to build, whereas previously it was kind of TIMTOWTDI (e.g default.nix evaluation is the default target and calling nix-build sans arguments builds that to `result`, and if you want more you write alternative nix files, the whole organisation of that is on you) These are very useful for project-oriented nix stuff. For system (nixos, nix-darwin)/environment/profile/home management I still prefer classic channels, which gives me a single, consistent nixpkgs source, kind of like BSD's base which is handled as a whole (except here it applies to the whole of packages). I am still able to locally override this or that by selectively pulling another nixpkgs (or other source) and use that to pick a specific package version (either forward or backward) but otherwise I stick to the single consistent one. It feels to me that using flakes for the whole system would be like using npm and having a whole recursive tree of `node_modules`. I certainly don't want to have a thousand different openssl around!
sullyj3 3y ago
> A 'flake' is more/less a set of inputs and a set of outputs. I'd say it's less complicated than a package.json file in an NPM project. It's conceptually comparably complicated, but the actual practical experience of writing flakes is much more complicated. This is not the fault of flakes specifically, but rather due to the complexity of nixpkgs. Although on second thoughts the fact that there are a bunch of libraries like flake-utils and flake-parts out there does seem to point at a verbosity UX issue.

lloeki 3y ago

For me the biggest benefits of flakes are: - flake-specific state is fully captured and locked - this locking applies for all platforms the flake targets - extreme ability to be composed The first two solve the same issue as Gemfile.lock, its the PLATFORMS section, and the platform annotations on each of its gem line, which allows `bundle lock` to lock not just for the platform it's being run on but all platforms that are targeted. It also canonicalizes the way to declare targets to build, whereas previously it was kind of TIMTOWTDI (e.g default.nix evaluation is the default target and calling nix-build sans arguments builds that to `result`, and if you want more you write alternative nix files, the whole organisation of that is on you) These are very useful for project-oriented nix stuff. For system (nixos, nix-darwin)/environment/profile/home management I still prefer classic channels, which gives me a single, consistent nixpkgs source, kind of like BSD's base which is handled as a whole (except here it applies to the whole of packages). I am still able to locally override this or that by selectively pulling another nixpkgs (or other source) and use that to pick a specific package version (either forward or backward) but otherwise I stick to the single consistent one. It feels to me that using flakes for the whole system would be like using npm and having a whole recursive tree of `node_modules`. I certainly don't want to have a thousand different openssl around!

sullyj3 3y ago

> A 'flake' is more/less a set of inputs and a set of outputs. I'd say it's less complicated than a package.json file in an NPM project. It's conceptually comparably complicated, but the actual practical experience of writing flakes is much more complicated. This is not the fault of flakes specifically, but rather due to the complexity of nixpkgs. Although on second thoughts the fact that there are a bunch of libraries like flake-utils and flake-parts out there does seem to point at a verbosity UX issue.