• toothbrush
    link
    fedilink
    arrow-up
    19
    ·
    edit-2
    11 months ago

    cool article! However, counterpoint: What is a flake?? The article doesnt say…

    Is it like a makefile?

      • toastal@lemmy.ml
        link
        fedilink
        arrow-up
        4
        ·
        11 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
          link
          fedilink
          arrow-up
          6
          ·
          11 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
            link
            fedilink
            arrow-up
            2
            ·
            11 months ago

            It was usually recommended to lock to inputs anyhow with all the fetchers requiring a hash which I hated having to manually update & like the UX flakes provides (I really wish they supported more than Git & Mercurial tho). You can still have different evals tho if you point to latest.tar.zstd or other non-hashed thing like a branch where the referred to can change & it won’t reproduce. I haven’t used channels in years, but doesn’t that just refer to the running system, not using Nix to build projects?

            • Atemu@lemmy.mlOP
              link
              fedilink
              arrow-up
              1
              ·
              11 months ago

              I haven’t used channels in years, but doesn’t that just refer to the running system, not using Nix to build projects?

              I have no idea what you’re trying to say here.

              • toastal@lemmy.ml
                link
                fedilink
                arrow-up
                1
                ·
                11 months ago

                Aren‘t channels for NixOS, and you’d use overlays for building packages? Now you can do that all with flakes.

  • RenardDesMers@lemmy.ml
    link
    fedilink
    arrow-up
    18
    ·
    11 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
      link
      fedilink
      arrow-up
      10
      ·
      edit-2
      11 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.

    • tuto@lemmy.world
      link
      fedilink
      brezhoneg
      arrow-up
      3
      ·
      11 months ago

      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

  • Mactan@lemmy.ml
    link
    fedilink
    arrow-up
    18
    ·
    11 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

    • d3Xt3r@lemmy.nzM
      link
      fedilink
      arrow-up
      6
      ·
      edit-2
      11 months ago

      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.

  • AItoothbrush@lemmy.zip
    link
    fedilink
    English
    arrow-up
    3
    ·
    11 months ago

    This a plea for help: is there any other distro that does immutability like nix without the configurstion of nixos. I love nix but its just so complicated. When something breaks i spend half an hour just to fix some small problem because i have to get the config then rebuild then test, etc. Idk if i was the one making nixos how would i fix it tho. Also its too teminal based for most people.

    • Atemu@lemmy.mlOP
      link
      fedilink
      arrow-up
      2
      ·
      11 months ago

      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.

  • TheOPtimal
    link
    fedilink
    ქართული
    arrow-up
    2
    ·
    11 months ago

    Guix is so good that it doesn’t need flakes

  • toastal@lemmy.ml
    link
    fedilink
    arrow-up
    2
    ·
    11 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.org
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 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
        link
        fedilink
        arrow-up
        2
        ·
        11 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.