Nix flakes are a feature of the nix package manager to make nix packages more reproducible.

A flake from cornflakes

This is a lot to take in; it’s basically an overview of all the interesting features of Nix. When starting out, you don’t need this kind of in-depth knowledge. I personally gathered most of what was covered here in over 6-12months of using it and I did just fine.

It might still not be for you but don’t take this as the reference point.

Yeah, it really isn’t for everyone. The advantagees it provides is mostly for developers and companies. If you’re a company, managing a NixOS fork is useful, so all users of the system are on the same page always.

Otherwise the package manager itself can be used on its own. It’s neat being able to use packages from basically any distro without even needing to use a VM.

Nix is daunting indeed, but cool for those who want such tooling

That’s only true you succumb to the hardcore Nix fanatics and follow their recommended “declarative” way. However, Nix, as a package manager, is perfectly usable - and accessible - with the imperative way, without having to subscribe to their religion and learn their language and terminology.

In the imperative path, Nix is as easy to use as any other package manager, yet it still retains many of the unique Nix features such as versioned packaged, instant rollback, non-root user-based installs etc.

It’s a shame because Nix is actually really cool and very easy to use if used this way - and especially useful on immutable distros, locked-down systems or distros which have a limited number of packages - but unfortunately, most people are missing out because the fanatics keep preaching the declarative way as if it’s the only option out there.

There’s the WIP NixOS-based SnowflakeOS that aims to make NixOS approachable for mere mortals but that’s still declarative configuration and of course still NixOS under the hood.

There’s a bunch of immutable distros out there that use OStree or some other imperatively managed snapshotting mechanism such as Fedora Silverblue or VanillaOS.

I sometimes write a flake with those 4 lines of Nix code, and it comes out just messy enough that tbh I’m happier adding an input to handle that. But I recently learned that the nixpkgs flake exports the lib.* helpers through nixpkgs.lib (as opposed to nixpkgs.legacyPackages.${system}.lib) so you can call helpers before specifying a system. And nixpkgs.lib.genAttrs is kinda close enough to flake-utils.lib.eachSystem that it might make a better solution.

Like where with flake-utils you would write,

flake-utils.lib.eachSystem [ "x86_64-linux" "aarch64-darwin" ] (system:
let
  pkgs = nixpkgs.legacyPackages.${system};
in
{
  devShells.default = pkgs.mkShell {
    nativeBuildInputs = with pkgs; [
      hello
    ];
  };
})

Instead you can use genAttrs,

let
  forAllSystems = nixpkgs.lib.genAttrs [ "x86_64-linux" "aarch64-darwin" ];
  pkgs = forAllSystems (system:
    nixpkgs.legacyPackages.${system}
  );
in
{
  devShells = forAllSystems (system: {
    default = pkgs.${system}.mkShell {
      nativeBuildInputs = with pkgs.${system}; [
        hello
      ];
    };
  });
}

It’s more verbose, but it makes the structure of outputs more transparent.

How do you compose Guix projects?

Nix the package manager uses the Nix language, and NixOS is a distro built on top of it. They’re all part of the same topic, and the article was talking about that.

Those last three are roughly the same topic and the subject of the article

deleted by creator

deleted by creator