computers i guess
      • toastal@lemmy.ml
        0·
        10 months ago

        Wut. It’s just as reproducible, flakes are mostly just a common unifying API with some extra CLI sugar for usability.

        • Atemu@lemmy.mlOP
          0·
          10 months ago

          While that is true, it’s also r13y on another level: Reproducible evaluation. That mostly stems from pure eval and locking.

          In the “before times”, you’d get your Nix expressions from some mutable location in the Nix path, so running i.e. a nixos-rebuild on your configuration could produce two different eval results when ran at two different times, depending on whether anything about your channel configuration changed in the mean time. This cannot happen with flakes as all inputs are explicitly given and locked.

          You could achieve the same using niv etc. before but that had its own issues.

  • toastal@lemmy.ml
    0·
    10 months ago

    I dunno, I don’t trust a guides still recommending flake-utils. You can make the same four loop in like 4 lines of Nix which is a smaller diff & doesn’t pollute your downstream consumers with a useless dependency. Flakes also don’t eliminate pointless builds, fileset or filtering the src can & the only tool with file tracking on by default is the Git VCS specifically (which also involves the intent to add flags which is the other side of annoying).

    • hallettj@beehaw.orgEnglish
      0·
      10 months ago

      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.

      • toastal@lemmy.ml
        0·
        10 months ago

        Saving the dependency is pretty big since each flake you import will bring along its jungle of dependencies now in your downstream project. I can’t think of a use case where < 10 lines is worth a dependency—especially since as you noted, lib has the glue right there for you to put it all together.

  • RenardDesMers@lemmy.ml
    0·
    10 months ago

    Probably not the goal of the author but I guess this article convinced me that nix/nixOS is not for me.

    • Atemu@lemmy.mlOP
      0·
      10 months ago

      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.

  • Mactan@lemmy.ml
    0·
    10 months ago

    nix is like the i3 of package managers. does it work sure but you’ll spend your 80% of your time learning code and configuration to make your sick packaging rice /sarcasm