NixOS daily driver
Go to file
2021-02-06 13:27:26 -07:00
.github Create FUNDING.yml 2021-02-02 01:02:06 -07:00
cachix cachix: add nix-community 2021-02-03 21:23:15 -07:00
compat compat: fixes 2021-01-23 16:45:10 -07:00
extern extern: move specialArgs here 2021-02-04 23:42:46 -07:00
hosts hosts: fix core 2021-02-06 13:26:17 -07:00
lib various refactors 2021-02-03 23:44:58 -07:00
modules create core branch without any profiles 2021-02-03 18:58:58 -07:00
nix Revert "ci: build iso" 2021-02-03 21:07:08 -07:00
overlays ci: fix ci after core creation 2021-02-03 19:35:10 -07:00
pkgs various refactors 2021-02-03 23:44:58 -07:00
profiles local: remove 2021-02-06 01:39:55 -07:00
secrets secrets: init empty secrets dir 2021-02-03 19:42:57 -07:00
shell various refactors 2021-02-03 23:44:58 -07:00
suites suites: mv to dir 2021-02-06 01:31:48 -07:00
unstable various refactors 2021-02-03 23:44:58 -07:00
users create core branch without any profiles 2021-02-03 18:58:58 -07:00
.editorconfig editorconfig: fixup 2020-12-30 01:00:12 -07:00
.envrc compat: fixes 2021-01-23 16:45:10 -07:00
.gitattributes .gitattributes: match the entire secrets/** subtree 2020-08-09 03:17:07 +02:00
.gitignore shell: ignore flk up generated configs 2021-01-11 13:20:52 -07:00
cachix.nix format: apply nixpkgs-fmt 2020-07-30 22:17:28 -06:00
CONTRIBUTING.md CONTRIBUTING.md: update pre-commit info 2021-02-03 19:51:08 -07:00
COPYING init 2019-12-02 22:18:30 -07:00
default.nix shell: workaround https://github.com/NixOS/nix/issues/4529 2021-02-06 13:27:26 -07:00
DOC.md suites: mv to dir 2021-02-06 01:31:48 -07:00
flake.lock flake.lock: Update 2021-02-02 01:29:36 -07:00
flake.nix various refactors 2021-02-03 23:44:58 -07:00
README.md various refactors 2021-02-03 23:44:58 -07:00
shell.nix compat: fixes 2021-01-23 16:45:10 -07:00

Since flakes are still quite new, I've listed some learning resources below.

Introduction

Herein lies a NixOS configuration template using the new flakes mechanism. Its aim is to provide a generic repository which neatly separates concerns and allows one to get up and running with NixOS faster than ever, while keeping your code clean and organized.

Some key advantages include:

  • A single home for all your Nix expressions, easily sharable and portable!
  • Skip the boilerplate, simply use the included nix-shell or direnv profile and get up and running with flakes right away.
  • Thanks to flakes, the entire system is more deterministic.
  • Systems defined under hosts are automatically imported into nixosConfigurations, ready to deploy.
  • Profiles are a simple mechanism for using portable code across machines.
  • Defined packages and modules, are automatically wired and available from anywhere. They are also sharable via their respective flake outputs.
  • Easily override packages from different nixpkgs versions.
  • Keep user configuration isolated and easily reusable by taking advantage of user profiles and home-manager.
  • Overlay files are automatically available and sharable.
  • Automatic NUR support.

For a more detailed explanation of the code structure, check out the docs.

⚠ Advisory

Flakes are still new, so not everything works yet. However, it has been to merged in nixpkgs via pkgs.nixFlakes. Thus, this project should be considered experimental, until flakes become the default.

Also, flakes are meant to deprecate nix-channels. It's recommended not to install any. If your really want them, they should work if you hook them into NIX_PATH.

Setup

There are a few ways to get up and running. You can fork this repo or use it as a template. There is a community branch with a bunch of useful profiles, modules, overlays, etc, already configured for you to use. Please consider adding your own expressions there if you feel they would be helpful for others.

The only hard requirement is nix itself. The shell.nix will pull in everything else.

Flake Templates

If you already have nix-command setup you can:

# for the core template with no profiles
nix flake new -t "github:nrdxp/nixflk" flk

# for the community template
nix flake new -t "github:nrdxp/nixflk/community" flk

Nix Only

Once you have this repo, you'll want to move or symlink it to /etc/nixos for ease of use. Once inside:

# probably want to use a separate branch for you config
git checkout -b my-branch

# This will setup nix-command and pull in the needed tools
nix-shell # or `direnv allow` if you prefer

# use nixos-generate-config to generate a basic config for your system
# edit hosts/up-$(hostname).nix to modify.
flk up

# The following should work fine for EFI systems.
# boot.loader.systemd-boot.enable = true;
# boot.loader.efi.canTouchEfiVariables = true;

# Set your locale
$EDITOR local/locale.nix

# install NixOS to bare metal
flk install yourConfig # deploys hosts/yourConfig.nix

# if you already have NixOS and just want to deploy your new setup
flk yourConfig switch

Note on flk up:

While the up sub-command is provided as a convenience to quickly set up and install a "fresh" NixOS system on current hardware, committing these files is discouraged.

They are placed in the git staging area automatically because they would be invisible to the flake otherwise, but it is best to move what you need from them directly into your hosts file and commit that instead.

Sharing

One of the great benefits of flakes is the ability to easily share your user defined packages, modules and other nix expressions without having to merge anything upstream. In that spirit, everything defined in this flake is usable from other flakes. So even if you don't want to use this project as a template, you can still pull in any useful modules, packages or profiles defined here.

From the command line:

# to see what this flake exports
nix flake show "github:nrdxp/nixflk"

# run an app
nix run "github:nrdxp/nixflk#someApp"

# start a dev shell for a given derivation
nix develop "github:nrdxp/nixflk#somePackage"

# a nix shell with the package in scope
nix shell "github:nrdxp/nixflk#somePackage"

From within a flake:

{
  inputs.nixflk.url = "github:nrdxp/nixflk";

  outputs = { self, nixpkgs, nixflk, ... }:
  {
    nixosConfigurations.example = nixpkgs.lib.nixosSystem {
      # ...
        modules = [
        nixflk.nixosModules.someModule
        ({
          nixpkgs.overlays = [ nixflk.overlay nixflk.overlays.someOverlay ];
        })
        # ...
      ];
    };
  };
}

Home Manager Integration

The home-manager nixos module is available for each host. It is meant to be used in the user profiles, you can find an example in the nixos user profile

The home-manager configuration for each user in each system is available in the outputs as homeConfigurations and the activation packages in hmActivationPackages.

This allows you to just build the home-manager environment without the rest of the system configuration. The feature is useful on systems without nixos or root access.

Lets say you want to activate the home configuration for the user nixos in the host NixOS.

With the flk script:

# You can build it using
flk home NixOS nixos
# and activate with
./result/activate

# Or do both like this
flk home NixOS nixos switch

Build an ISO

You can make an ISO out of any config:

flk iso yourConfig # build an iso for hosts/yourConfig.nix

Hardware Specific Profile for a Single Host

Find out the fitting nixos-hardware profile for the hardware of your host, then find the corresponding modules in the flake and add it to the configuration. For example for a Dell XPS 13 9370 the host configuration would contain:

{ hardware, ... }:
{
  imports = [ hardware.dell-xps-13-9370 ... ];
  ...
}

Use a Package from NUR

NUR is wired in from the start. For safety, nothing is added from it by default, but you can easily pull packages from inside your configuration like so:

{ pkgs, ... }:
{
  environment.systemPackages = with pkgs; [ nur.repos.<owner>.<package> ];
}

Resources

Flake Talk:

Flake talk at NixConf

License

This software is licensed under the MIT License.

Note: MIT license does not apply to the packages built by this configuration, merely to the files in this repository (the Nix expressions, build scripts, NixOS modules, etc.). It also might not apply to patches included here, which may be derivative works of the packages to which they apply. The aforementioned artifacts are all covered by the licenses of the respective packages.