Should I use flake or not

I’m a beginner to NIXos and I have set up a KDE plasma configuration. I’ve also set up home manager as a module to configure OBS studio with the background removal extension. Probably in the future I will setup a Window Manager such as hyprland but I’m not sure of that. I would like to use the same or roughly the same configuration for my laptop, but I don’t think that I will use my configuration for more than two computers of my own. I have a traditional configuration.nex setup and not a flake.
To set up the Flake looks very complicated to me. Do I have any advantages if I switch to flake or not? Will there be a time there is compulsory to switch from traditional setup to flakes? I would like to run my systems for a longer time. Thanks in advance for the advice.

My €0.02: Maybe don’t switch to flakes for your NixOS configuration yet. I did last year for a while. There are a few cool things you can do with it, like have one configuration file for multiple machines. However, you can accomplish something very similar with include files.

Note that you can include flakes in your non-flake-based configuration.nix.

The number of people using flakes for their NixOS config was pretty small at the time, and probably still is. I was concerned that if I ran into problems, there wouldn’t be many people who could answer questions. Now that I feel pretty comfortable with flakes, I am considering giving it another go… but I’ll probably still wait a bit.

Flakes are getting simpler all the time, with people developing new functions that make flake definitions simpler. I wouldn’t be surprised if the task of using a flake to configure NixOS became a lot simpler over time.

1 Like

You can see how I handle multiple machines in a traditional NixOS configuration here: GitHub - mhwombat/nixos-config: My NixOS configuration

It is very modular. I have a very small configuration.nix that is the same for all machines except for the hostname. It includes the other configuration files, including the host-specific one, which by convention I call hostname.nix.

let hostname="wombat11k";
  imports =
    [ # Include the results of the hardware scan.
      (./. + "/${hostname}.nix")      # THIS LINE INCLUDES THE MACHINE-SPECIFIC SETTINGS
1 Like

Thank you for your reply, I think I’ll wait for some time and experiment with the configuration that I have now. From what I have seen NIXOS is nice for now because the large package library and relatively easy to configure things as automatic updates etc.

I switched to the flake-based NixOS configuration on my laptop for more than two years. It works as well as the channel-based setup, with two additional benefits:

  1. It’s reproducible and updatable. In the flake-based setup, all the input revisions (channel revisiots) are recorded inside a text file flake.lock in the flake-based setup. You could bring flake.nix, flake.lock and other configuration files to another computer and set them up with exactly the same version of everything. You could update input-by-input with nix flake lock --update-input inputname, or update all the inputs by nix flake update without manually changing the hashes.

    In contrast, the only way to ensure reproducibility for the channel-based setup when setting up on another machine (or after system-wide reinstallation) is not to use the channel, but pin everything with fetchers and hashes instead. When updating, you’ll need to nix-prefetch every pinned source and update the hashes manually inside the configuration files. That makes updating laborious, and being reluctant to update exposes the setup to the risk of newly-discovered security vulnerabilities.

  2. The configuration can be passed into other flakes. For example, I use Home Manager to manage my per-user dot files, and I could get the system-level configuration by adding the system flake as a flake input:

      inputs.system-config.url = "git+file:///etc/nixos";

    There are two use cases for me:

    1. pkgs from the system: It’s sometimes required to ensure that the version of some user-installed packages be compatible to some others installed system-wide. That’s when
      pkgsSystem = inputs.system-config.legacyPackages.${system};
      comes in handy.
    2. Home Manager xsession configuration with the desktop environment installed system-wide.