Any default config for reproducible configurations?

8

General advantages include everything automatically delivered by flakes, ie:

  • deterministic evaluation.
  • Easily pinning nixpkgs, as well as using multiple nixpkgs versions.
  • easily exporting packages, modules, or whole system configurations to other flakes.
  • overriding or importing other flakes to extend configurations trivially

Advantages specific to my repo:

  • Super easy to get up and running
  • Every file in hosts/<file>.nix is automatically added as a valid NixOS configuration available in flake outputs, without having to wire it up yourself.
  • Super modular, allowing multiple system declarations. And clean separation of various concerns.
  • Resuse of different profiles between different machines, and mix and matching profiles and sub-profiles to easily build a NixOS configuration from existing code is as trivial as an imports statement.
  • Secrets automatically encrypted using git-crypt
  • All flake outputs wired up automatically to so you can focus on writing interesting nix expressions rather than boilerplate.
  • If adoption catches on, having a standardized directory structure would make switching contexts, say from one job to the next a lot simpler and faster.

answer to overlays question

Well I’ve wired up the flake to automatically export any packages defined in the pkgs directory as an overlay which can then be imported into another flake. This should be trivially combinable with your own overlays.

Concrete example.

{
  # flake.nix
  inputs.<friends-flake>.url = "<flake-uri>";

  outputs = args@{ self, nixpkgs, <friends-flake> }: {
    ...
  };
} 

# hosts/default.nix -- basis for all configurations
# it is the only file with direct access to all flake inputs
...
  global = {
    ...
    nixpkgs.overlays = self.overlays ++ args.<friends-flake>.overlays; 
    ...
  };
...

The workflow for adding a package to the overlay is essentially exactly the same as adding a package to nixpkgs itself. This is intential to provide a kind of staging area for new package development.

The only difference, is instead of adding a top level package definition to all-packages.nix as in nixpkgs, you add the package definition to pkgs/default.nix in the exact same way. The rest is taken care of automatically by flake.nix.

Since flakes are still not merged into master, there are still some limitations that will be resolved once it is. For example, the flakes pr repo is a bit out of date, so for now I am pointing nixpkgs to a fork that is just the flakes pr rebased onto a more recent version of master.

Once it actually gets merged you can trivially specify multiple versions of nixpkgs as inputs by simply given them unique names and specifying their flake uri directly, e.g. “nixpkgs/release-19.09” or whatever the finalized uri semantics end up looking like.

1 Like